собственные - список исключений java




Каково общее правило для создания исключения в Java? (5)

Я был в обеих ситуациях:

  • Создание слишком большого количества пользовательских исключений
  • Использование слишком большого общего класса Exception

В обоих случаях проект начался нормально, но вскоре он стал накладным для поддержания (и рефакторинга).

Итак, какова наилучшая практика создания ваших собственных классов исключений?


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

Одним из советов было бы создание исключений по мере необходимости, и если станет очевидным, что один тип исключения является дубликатом другого, реорганизуйте его, объединив два. Конечно, это помогает, если подумать о том, чтобы с самого начала было структурировать исключения. Но обычно используйте пользовательские исключения для всех случаев, которые не имеют соответствия 1: 1 существующим исключениям для конкретной ситуации.

С другой стороны, NullPointerException и IndexOutofBoundsException s могут часто быть подходящими. Не поймите их, хотя (за исключением ведения журнала), поскольку они являются ошибкой программирования, что означает, что после их броска программа находится в неопределенном состоянии.


Специалисты по Java написали сообщение об исключениях в Java и в нем перечислены несколько «лучших практик» для создания исключений, которые приведены ниже:

  • Не записывайте собственные исключения (существует множество полезных исключений, которые уже являются частью Java API)

  • Напишите полезные исключения (если вам нужно написать свои собственные Исключения, убедитесь, что они предоставляют полезную информацию о возникшей проблеме)


Мое собственное правило:

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

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


Не делайте то, что сделали разработчики в моей компании. Кто-то создал [sic] InvalidArguementException, которое parallels java.lang.IllegalArgumentException, и теперь мы используем его (буквально) сотен классов. Оба указывают, что метод был принят незаконным или несоответствующим аргументом. Поговорите об отходах ...

Джошуа Блох рассказывает об этом в « Руководстве по эффективному Java-программированию» [моя библия о первом обращении к передовой практике]. Глава 8. Исключения. Пункт 42: Благоприятствовать использованию стандартных исключений . Вот что он говорит,

Повторное использование ранее существовавших исключений имеет несколько преимуществ. Главный из них, это делает ваш API легче учиться и использовать, потому что он соответствует установленным соглашениям, с которыми программисты уже знакомы [ мой акцент, а не Блоха ]. Ближайшим вторым является то, что программы, использующие ваш API, легче читать, потому что они не загромождают незнакомых исключений. Наконец, меньшее количество классов исключений означает меньшую площадь памяти и меньшее время, затрачиваемое на загрузку классов.

Наиболее часто используемым исключением является исключение IllegalArgumentException. Это, как правило, исключение для того, чтобы выбросить, когда вызывающий абонент передает аргумент, значение которого неуместно. Например, это было бы исключение для броска, если вызывающий абонент передал отрицательное число в параметр, представляющий количество повторений некоторого действия.

Тем не менее, вы никогда не должны бросать Исключение. Java имеет хорошо подобранную, разнообразную и целенаправленную совокупность встроенных исключений, которые охватывают большинство ситуаций и описывают исключение, которое произошло достаточно хорошо, чтобы вы могли исправить эту причину.

Будьте дружелюбны к программистам, которые должны поддерживать ваш код в будущем.


При создании собственного исключения:

  • Все исключения должны быть ребенком класса Throwable

  • Если вы хотите написать проверенное исключение, которое автоматически принудительно выполняется с помощью правила Handle или Declare, вам необходимо расширить класс исключений

  • Если вы хотите написать исполняемое исполнение, вам необходимо расширить класс исключения Runtime.





exception