Исключение исключение исключающего указателя не является хорошей практикой, является ли исключение хорошим?

Я слышал, что ловить NullPointerException - плохая практика, и я думаю, что это разумно. Предоставление NullPointerException для распространения вверху позволит обнаружить что-то не так. Но много раз я видел, как многие мои друзья ловили Exception напрямую, поэтому им не нужно беспокоиться обо всех различных исключениях, которые могут возникнуть в приведенном выше коде. Это хорошая практика? Каковы другие виды исключений, которые лучше всего оставить необработанными? И кроме того, мне также имеет смысл обрабатывать NullPointerException по определенному коду, где мы уверены в источнике исключения. Итак, когда есть исключения, которые следует обрабатывать, и когда они не должны обрабатываться? И каков будет возможный список исключений, которые лучше всего оставить необработанными?

Ответ 1

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

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

  • Имеет ли смысл обрабатывать исключение на этом уровне? Если да, тогда обработайте его. Если нет, то распространяйте.
  • В сочетании с первым правилом "обработка" также может означать, ловить, обертывать и повторно бросать. Это способ предотвращения абстракции-утечки, так что вызывающие элементы вашего метода не должны знать о базовой реализации.
  • Пустой блок catch не означает, что вы обработали исключение. Это называется "глотание"; по крайней мере, вы хотите зарегистрировать исключение. Иногда исключение происходит на самом деле, является частью логического потока вашего кода, и поэтому вы можете сделать что-то особенное (но это помилование каламбура, исключение, а не правило. Лучше проверить ситуации, которые вызывают исключения вместо того, чтобы включать их в логический поток вашего кода).

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

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

Ответ 2

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

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

Если, например, вы были связаны по бизнес-причинам с API, в котором есть ошибка внутри, и иногда бросает нулевой указатель, было бы вполне законно его поймать, что-то сделать или сообщить пользователю лучшее сообщение, Если позволить "null" ударить по пользовательскому интерфейсу только потому, что кто-то сказал, что "Исключение ошибки Null Pointer is bad" не имеет смысла!

Ловкость java.lang.Exception может быть законной в конкретных случаях, но в целом "Я ленивый" не является одним из них.:) Например, если вы внедряете API и хотите абсолютно уверенно, что из этого никогда не будет исключение, которое не входит в спецификацию, вы можете поймать Exception и обернуть его в определенном вами случае, которое вы определили.

Ответ 3

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

NullPointerException обычно является результатом ошибки в коде. Как вы можете разумно исправить это в блоке catch?

Не беспокоиться об исключениях - это не хорошая практика.

Ответ 4

В общем, единственное время, когда вы должны поймать исключение, - это то, что вы можете обработать его каким-то значимым образом. Если вы не можете, вы должны просто позволить пузыриться до вершины и прекратить процесс. Например, можно ли каким-либо образом осмыслить проблему с ошибкой NullPointerException или I/O? Думаю, что нет.

Мои правила обработки исключений:

  • В общем, не перехватывайте исключения, если вы не можете их обработать каким-либо значимым образом.
  • Поймать исключения на границах процесса/машины, зарегистрировать исключенное поймать вместе с любым доступным для вас контекстом и повторно бросить его. Если исключение является настраиваемым исключением, вы можете обернуть его за исключением типа, известного/полезного для процесса вызова, и выбросите его.
  • Вы также можете перехватывать исключения на низком уровне, где у вас есть самый доступный контекст времени выполнения, регистрировать исключение и связанный с ним контекст, а затем переустанавливать исключение.
  • При повторном создании используйте throw ;, а не throw caughtException ;. Использование прежнего синтаксиса сохраняет исходную трассировку стека; использование последнего синтаксиса создает новую трассировку стека, начиная с throw caughtException ; - вы теряете весь контекст и стек вызовов до точки, в которой было обнаружено исключение.
  • Вы можете, если захотите, перехватить исключения на высоком уровне и изящно завершить процесс, регистрируя информацию об исключениях, чтобы помочь отлаживать и исправлять лежащую в основе проблему.

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

Для получения дополнительной информации см. книгу Бертран Майерса, Объектно-ориентированное программное обеспечение, 2-е изд..

Ответ 5

Основное правило об исключении catching заключается в том, что вы должны знать, почему вы это делаете. Класс исключений улавливается в случаях, когда программист хочет выполнить общую обработку ошибок, и ему все равно, что именно произошло, главное, что-то пошло не так. В этом случае он может решить откат транзакции или выполнить некоторую очистку. Если вы ловите определенное исключение, попробуйте применить одно и то же правило. Я точно знаю, почему вы это делаете, тогда это нужно сделать. Но это очень редкий случай, когда кто-то хотел бы сделать что-то действительно особенное в случае NPE.

Ответ 6

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