Почему у проекта есть RuntimeException?

Question

Есть ли смысл иметь исключение com.myco.myproj.MyProjRuntimeException, какой комплект расширяет RuntimeException?

Answer 1

Да. Do , выбрасывание непроверенных исключений и их подкласс.

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

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

Так почему бы не бросить RuntimeException? Это не элегантно , а менее читабельно . Сделайте это вашим собственным исключением, которое вытекает из него, даже если это ни по какой другой причине, кроме как быть более точным при создании исключения.

Answer 2

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

Answer 3

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

Answer 4

Многие люди (включая меня и разработчиков C #) считают , что проверенные исключения являются неудачным языковым экспериментом и избегают их. Затем создание собственной иерархии исключений в RuntimeException является очевидным шагом.

Answer 5

в эффективной Java, Джошуа Блох пишет:

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

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

Answer 6

Это хороший стиль для поддержания собственной иерархии исключений.

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

Answer 7

Не совсем. Дополнительную информацию, которую вы получаете от отображения имени исключения в трассировке стека, можно получить, просто задав строку сообщения стандартного RuntimeException. Однако (если подумать), было бы полезно создать подкласс RuntimeException просто для добавления пользовательской строки в любое сообщение.

Я склонен делать только специально проверенные исключения; как правило, стандартные непроверенные исключения уже охватывают достаточно потенциальных случаев.

Answer 8

Исключения подкласса основаны на способах их обработки , а не на том, кто их написал ...

Обычно исключение времени выполнения не может быть обработано иначе, чем регистрация ошибки и, возможно, отображение сообщения об ошибке.

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

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

Это вполне нормально для подкласса RuntimeException (если существующие подклассы не подходят)

Документирование непроверенных исключений. Будьте консервативны с проверенными исключениями и не создавайте иерархии.

Answer 9

Род Джонсон (Rod Jonhson) написал об этом в Expert один на один, проектирование и разработка J2EE, и, как и в ответе Тома, RuntimeException следует использовать для ошибок программирования. Хорошим примером является SQLException, API доступа к данным более низкого уровня должен перехватить их и выдать свое собственное «SQLRuntimeException», так как большую часть времени вызывающий код не может ничего сделать с исключением. Таким образом, ваши API-интерфейсы более высокого уровня не обязаны перехватывать или переносить исключения более низкого уровня в своей подписи, что делает код более простым и более ориентированным на бизнес-область.