Каково общее правило больших пальцев для создания исключения в Java?

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

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

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

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

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

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

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

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

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

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

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

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

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

Это мой rule-o-thumb.

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

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

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

Мое собственное эмпирическое правило:

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

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

В то время как создание собственных исключений:

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

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

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

Не ешьте исключения, бросьте их https://stackoverflow.com/a/921583/1097600

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

IllegalStateException
UnsupportedOperationException
IllegalArgumentException
NoSuchElementException
NullPointerException

Выбрасывайте непроверенные исключения.

Пример

public void validate(MyObject myObjectInstance) {
    if (!myObjectList.contains(myObjectInstance))
        throw new NoSuchElementException("object not present in list");
}