Проверено эквивалентно IllegalArgumentException? - PullRequest
18 голосов
/ 18 марта 2010

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

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

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

Ответы [ 3 ]

4 голосов
/ 18 марта 2010

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

3 голосов
/ 18 марта 2010

Вопросы:

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

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

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

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

0 голосов
/ 28 августа 2017

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...