Java, специфичные для класса исключения против стандартных исключений

Question

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

Сначала я решил определить исключения, специфичные для каждого класса, однако оказалось, что большинство из них являются просто расширениями существующих исключений времени выполнения (например, FooNegativeIntArgumentException extends IllegalArgumentException, FooNullBarException extends NullPointerException) с конкретными сообщениями. *

Каковы компромиссы определения новых исключений по сравнению с использованием существующих? Существуют ли какие-либо соглашения / лучшие практики?

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

Answer 1

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

1. Когда выкидывать разные типы исключений? Создайте разные типы исключений для каждого симптома, которые могут программно обрабатываться по-разному.

2. Когда создавать пользовательские типы исключений? Создайте пользовательский тип исключения, когда необходимо аннотировать исключение дополнительной информацией, чтобы помочь в программной обработке симптома.

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

Answer 2

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

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

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

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

Answer 3

С Эффективная Java

Вы должны отдавать предпочтение использованию стандартных исключений и использовать набор непроверенных исключений библиотек платформы Java, которые охватывают то, что вы описали. Повторное использование исключений имеет следующие преимущества:

Упрощает изучение и использование вашего API, поскольку оно соответствует установленным соглашениям, с которыми программисты уже знакомы

Меньше классов исключений означает меньший объем памяти и меньше времени, затрачиваемого на загрузку классов.

Answer 4

Возможно ли, что вызывающему абоненту нужно будет перехватить исключение FooNegativeIntArgumentException, а не IllegalArgumentException?

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

Answer 5

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

Answer 6

Компромисс? Много работы, много кода для поддержки и время - деньги . Я бы посоветовал: определять новые исключения, только если они вам нужны для фильтрации журналов, детальной обработки исключений или отладки (установите точку останова для особого типа исключения).