Когда бы вы предпочли объявить исключение, а не обрабатывать его в Java?

Question

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

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

Редактировать: я имел в виду вызов метода вместо суперкласса в последней строке.

Answer 1

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

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

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

Answer 2

Я думаю, под "суперклассом" вы подразумеваете код, который вызвал ваш метод.

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

В общем, если вы не знаете, как решить проблему, не надо. Эфир передает его или переносит в другое исключение.

Answer 3

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

Например:
если DAO (уровень доступа к базе данных) получает исключение SQLException, он генерирует специальное DAOLayerException, которое перехватывается бизнес-уровнем, который, в свою очередь, выдает исключение, которое перехватывается уровнем представления. Это было для непроверенных исключений.

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

Answer 4

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

Вот полубетонный пример. Допустим, у меня есть веб-приложение, которое реализовано в виде последовательности состояний и действий . Предположим, что во время обработки состояния при доступе к базе данных создается SQLException. Это не произойдет во время нормальной работы моего приложения; это произойдет только в том случае, если с базой данных что-то не так.

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

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

Answer 5

Если вы не можете обработать ошибку в точке разумным способом (например, отобразить сообщение об ошибке, выбрать альтернативный путь и т. Д.), Просто дайте ему всплыть.

Answer 6

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

Для экземпляра у меня могут быть некоторые вспомогательные методы в методе sendEmail. Если вспомогательный метод скажет, что checkEmailAddress () сгенерировал исключение, я бы хотел, чтобы sendEmail знал об этом, что могло бы дополнительно распространить его или сделать предупреждение в интерфейсе пользователя «электронная почта неверна»

Answer 7

Вы запросили пример, а вот обычный.

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

Answer 8

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

Кроме того, существует множество ошибок Java, которые вы никогда не обнаружите, например, OutOfMemoryError. Вы можете поймать их, но не можете правильно с ними справиться.