Ловля нулевых указателей исключений

Question

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

Рассмотрим,

if(myVariable==null){ 
     doSomethingAboutIt(); 
} 
else carryOn(myVariable); 

и

try{ 
    carryOn(MyVariable); 
}catch(NullPointerException e){ 
     doSOmethingAboutIt();} 

ли оба эти блоки кода по существу то же самое? Есть ли какая-то причина выбора второго подхода? Конечно, это было бы bette rif myVariable никогда не было нулевым, но кажется, что лучший способ проверить это - сделать простой оператор if.

Answer 1

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

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

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

Answer 2

Ну, сам по себе carryOn(MyVariable); никогда не будет бросать NPE, если только что-то еще в пределах carryOn ссылается на вызов метода или свойства в экземпляре null.

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

я бы утверждать, что это приводит к «более чистого» кода, а также ,

Смотрите также: - Java try/catch performance, is it recommended to keep what is inside the try clause to a minimum? - Try Catch Performance Java

Answer 3

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

Answer 4

Первый подход лучше, чем исключение catching, потому что есть некоторые нарушения производительности. Наилучшим подходом, на мой взгляд, является применение Null Object pattern. Библиотека Guava предоставляет класс Optional, который вы можете использовать вместо того, чтобы создавать свои собственные.

Answer 5

Нет, эти кодовые блоки не совпадают.

В первом блоке кода вы проверяете, является ли myVariablenull, и вы делаете это только в один момент времени. Позже myVariable может стать null и в конечном итоге бросить NullPointerException. Если это произойдет, второй фрагмент кода поймает исключение, но первое не будет.

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

Используйте первый фрагмент кода.