Правильное использование RuntimeException?

Возможный дубликат:
В Java, когда я должен создать проверенное исключение и когда это должно быть исключение во время выполнения?

Когда я должен получить исключение из RuntimeException вместо Exception?

A RuntimeException не должен быть объявлен в предложении method throws, который может быть хорошим, поскольку он не должен быть специально указан или bad потому что это хорошая практика явно объявить исключение метода.

Мысли?

Ответ 1

От Непроверенные исключения - противоречие:

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

Обратите внимание, что исключенное исключение - это одно производное от RuntimeException, а проверенное исключение - одно из Exception.

Зачем бросать RuntimeException, если клиент не может ничего сделать для восстановления из исключения? В статье объясняется:

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

Ответ 2

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

При реализации обработки исключений в качестве аспекта (разделяющего принцип дизайна беспокойства) в большинстве современных фреймов вы должны декларативно обрабатывать исключения и связывать конкретные блоки обработки исключений, а не жестко кодировать их. Одним из хороших примеров этого является шаблон JDBC в Spring, который преобразует все исключения SQL в RuntimeException, поэтому разработчик не пишет блоки try catch при написании логики доступа к данным. вы можете описать обработчик описателей декларативно, что может обеспечить различное поведение в dev env. и различное поведение в производстве. Аналогичная реализация существует и в классе Action Struts 1.x, где объявлен метод execute для исключения Exception, и для обработки особых исключений имеется отдельный ExceptionHandler, отображаемый в struts-config. Хотя это не пример исключения RuntimeException, но принцип проектирования тот же, что и разделение проблемы нормального выполнения и обработки исключений.
Другое использование RuntimeException находится в EJB и других менеджерах транзакций, где в транзакциях находится контроллер по контейнеру. В таких контейнерах условно, если вы выбросите RuntimeException из своего кода, транзакция будет отката - то же самое не произойдет, если вы выбросите Exception

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