Что такое общее правило тумб для создания исключений в Java?

голоса
17

Я был в обоих случаях:

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

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

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

Задан 25/08/2008 в 22:46
источник пользователем
На других языках...                            


7 ответов

голоса
15

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

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

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

Ответил 25/08/2008 d 23:50
источник пользователем

голоса
10

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

Джошуа Блох охватывает это в Effective Java Programming Language Guide [моей библией первой инстанции по наилучшей практике] Глава 8. Исключения Пункт 42: Фавор использование стандартных исключений . Вот немного о том, что он говорит,

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

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

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

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

Ответил 19/10/2008 d 17:04
источник пользователем

голоса
8

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

try {
     doIt();
} catch (ExceptionType1 ex1) {
     // do something useful
} catch (ExceptionType2 ex2) {
     // do the exact same useful thing that was done in the block above
}

то, очевидно, дополнительные типы исключений не нужны. Слишком часто я вижу (или я вынужден писать) код, как это потому, что код называют переусердствовал в своем создании новых типов исключений.

Ответил 25/08/2008 d 23:23
источник пользователем

голоса
6

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

Это мое правило-о-палец.

Ответил 26/08/2008 d 05:46
источник пользователем

голоса
4

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

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

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

Ответил 25/08/2008 d 22:58
источник пользователем

голоса
3

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

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

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

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

Ответил 15/02/2014 d 22:31
источник пользователем

голоса
3

Мое правило:

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

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

Ответил 26/08/2008 d 19:03
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more