Проверено эквивалентно исключению IllegalArgumentException?

У меня есть метод, который принимает перечисление в качестве параметра и возвращает некоторую информацию, зависящую от этого параметра. Однако это перечисление содержит некоторые значения, которые не должны обрабатываться, и должны вызывать условие ошибки. В настоящее время метод генерирует исключение IllegalArgumentException, но я хотел бы, чтобы это было исключенным исключением, чтобы заставить вызывающих абонентов его поймать (и изящно вернуть, зарегистрировав ошибку). Есть ли что-то подходящее или я должен создать свой собственный подкласс Exception?

Я открыт для других моделей. Разумная реакция будет заключаться в том, что все значения перечисления должны обрабатываться, но это не так. Когда новое значение добавляется в перечисление, я хочу убедиться, что этот метод делает правильную вещь - предупредить человека предпочтительнее использовать в этом случае значение возвращаемого значения по умолчанию.

Спасибо за любой совет.

Ответ 1

Вы можете, конечно, создать проверенное исключение из своего собственного (например, UnhandledEnumType), или вы можете поймать и обработать исключение IllegalArgumentException. Звучит немного подозрительно, что нужно обрабатывать только некоторые значения перечисления. Одна из целей перечисления - привязать значения к определенному набору значений, и я ожидаю, что все будут обработаны. Если вы беспокоитесь о добавлении новых, у вас должен быть тест, который проверяет правильность обработки всех значений (используя метод values () перечисления, чтобы убедиться, что все они протестированы).

Ответ 2

Вопросы:

Насколько "нормальными" являются случаи, когда метод вызывается с неподходящим параметром enum?
Вы можете обработать эти случаи изящно, а затем продолжить обработку?

Из того, что вы описали, оно не является "нормальным" (происходит только при добавлении нового значения перечисления, и метод не обновляется должным образом - то есть когда была введена ошибка). Поэтому для меня это больше похоже на случай RuntimeException (т.е. Непроверенный). Вызывающие этого метода могут по-прежнему улавливать неконтролируемое исключение, если они действительно этого хотят, но они не вынуждены.

OTOH Я бы попытался устранить описанный вами случай, перемещая данные, возвращаемые вашим методом прямо внутри перечисления. Таким образом, всякий раз, когда добавляется новое значение enum, невозможно забыть о соответствующих данных.

Если вам интересно, вы можете проверить этот учебник.

Ответ 3

Как насчет экземпляра InstantiationException? Брошено, когда приложение пытается создать экземпляр класса с использованием метода newInstance в классе Class, но указанный объект класса не может быть создан. Создание экземпляра может завершиться неудачей по ряду причин, включая, но не ограничиваясь: объект класса представляет собой абстрактный класс, интерфейс, класс массива, примитивный тип или пустоту класс не имеет нулевого конструктора