Является ли проверка исключений в коде или использование try-catch лучшей практикой в ​​Java?

Question

Мне кто-то упомянул, что перехват всех исключений не обязательно является хорошей практикой (например, NullPointerException). Я ищу объяснение того, когда это хорошо, когда это не так, и почему это так: D

Спасибо !!

badPanda

Answer 1

Короче говоря:

Проверенные исключения для ловли

Необработанные исключения и ошибки можно оставить всплывающими. (это подклассы RuntimeException и Error).

Это связано с тем, что проверенные исключения являются «ожидаемыми» и программа может восстановить их. Непроверенные исключения являются такими, из которых программа не может восстановиться (легко).

В руководстве Sun говорится (речь идет о решении, какое исключение вы должны создать, но оно также информативно с другой стороны - то есть при использовании исключений):

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

Answer 2

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

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

Это не верно в 100% случаев, но как общий подход, как это работает,особенно на Java.

Answer 3

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

Если это просто, определенно проверьте наличие ошибки и устраните ее, а не используйте try-catch. Например, если вы можете справиться с неверным вводом, проверив его и напечатав тип сообщения «Пожалуйста, попробуйте еще раз», вы не будете использовать try-catch.

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

Answer 4

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

Answer 5

RuntimeExceptions можно (в большинстве случаев) считать «ошибками программирования». Например, подумайте о том, чтобы вытолкнуть объект из стека, прежде чем проверять, действительно ли он содержит какие-либо элементы. В правильной реализации должен быть какой-то метод isEmpty () для проверки состояния стека. Если программист ленится или забывает проверять стек, должно быть сгенерировано исключение, указывающее на ошибку программирования.

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

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

Answer 6

Исключения, которые не вызваны ошибками программирования и / или могут быть восстановлены, должны быть перехвачены. Других не должно быть. В Java обычно проверенные исключения должны быть перехвачены, а RunTimeExceptions и Errors - нет.

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

Answer 7

Я всегда реализую try...catch(Throwable) (Throwable действительно является ошибкой, и ваше приложение не должно выполнять никаких дальнейших операций после того, как оно получит одну из них) в ОДНОЙ точке моего кода, когда крайне важно знать, что произошло это может быть зарегистрировано. Обычно это метод main.

У меня также есть попытка ... catch (Exception) в классе runnable или в классе, который обрабатывает, например, одну запись, которая может обрабатываться независимо от других. В этом случае приложение должно двигаться дальше, даже если часть его обработки завершится неудачно - не имеет значения, знаю ли я, какое исключение будет выдано или нет - я ловлю исключение, регистрирую его, я отменяю эту запись обработки, и я иду дальше.

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

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