Этот ответ может быть длинным, но я думаю, что оно того стоит.
Кажется, что не очень хорошая идея поймать nullpointerexception.
Вы правы, вы не должны перехватывать ни NullPointerException, ни какие-либо исключения во время выполнения.
Если это так, то почему это бросается методами? Должен ли он быть пойман с исключением?
Используется для обозначения ошибки программирования. Эти ошибки программирования могут и должны быть исправлены с помощью кода (то есть они могут быть предотвращены)
Кроме того, если я сталкиваюсь с параметром, который является нулевым, как мне обращаться с ним? [...] (предположительно, не бросать npe)?
Это зависит от того, что вы хотите с ним делать. Для некоторой логики может быть разрешено значение null. Если это так, вы проверяете наличие нуля и что-то с этим делаете, либо предоставляете значение по умолчанию, либо избегаете отправки сообщений на нуль.
Например. Допустим, у вас есть информационная система для выставления счетов, и у вас есть этот код, в котором вы сохраняете информацию о клиенте, и вы можете дополнительно сохранить дополнительную информацию о клиенте.
В этом случае необязательное сообщение может быть нулевым, и ваш код должен проверять его наличие.
Например:
/**
* ...
* @param - OptionalMessage may be null, include anything else you wan to save.
*/
public void sendCustomerInformation( Customer c , OptionalMessage optionalMessage ) {
SomeMessage message = SomeMessage.createMessage();
message.setHeader( c.name() );
message.setCustomerInformation( c );
if( optionalMessage != null ) { // is optional? handle it
message.add( optionalMessage.status() );
message.add( optionalMessage.summary() );
message.add( optionalMessage.message() );
}
}
}
Вы подтверждаете наличие нуля и документируете его.
Но в этом же коде в качестве параметра также указан customer, в этом случае вы можете:
а) Ничего не делать
b) Подтвердите также
c) Создайте другое исключение в соответствии с уровнем абстракции на этом уровне.
Например, приведенный выше код ничего не делает a) . Это приведет к исключению NullPointerException, при котором вызывается код c.name(), и это следует отлавливать на ранних этапах тестов разработки. Кроме того, это должно быть задокументировано в параметре и бросках в javadoc.
/**
* ...
* @param c - The customer whose information is to be sent. NotNull
* ...
* @throws NullPointerException if the customer is null
*/
public void sendCustomerInformation( Customer c , OptionalMessage optionalMessage ) {
SomeMessage message = SomeMessage.createMessage();
...
Если кто-нибудь вызовет этот метод с нулем, Npe укажет, что он что-то не так кодировал. Плюс, Npe, очень быстро скажет, что и где была ошибка кодирования (при вызове sendCustomerInformation с нулевым клиентом.
опция b) Проверить. Это может быть тот случай, когда вы можете разрешить обработку нулевого клиента (это не имеет смысла, но это вариант)
В этом случае вы можете проверить его и вернуться преждевременно ( я закончил способ)
public void sendCustomerInformation( Customer c , OptionalMessage optionalMessage ) {
if( cusomer == null ) { return; // I'm done! }
// else
SomeMessage message = ...
..
}
Или может создать замену:
public void sendCustomerInformation( Customer c , OptionalMessage optionalMessage ) {
if( cusomer == null ) { c = new EmptyCustomer() ;}
// else
SomeMessage message = ...
..
}
option c) Это похоже на a, но в этом случае вы выбрасываете исключение в соответствии с уровнем абстракции. Например, если это будет показано конечному пользователю в графическом интерфейсе или что-то еще, может не иметь смысла просто бросать Npe:
public void sendCustomerInformation( Customer c , OptionalMessage optionalMessage ) {
if( cusomer == null ) {
// oh oh something went wrong.
log.fatal("Invalid argument on \"sendCustomerInformation\" );
throw new MyApplicationException("Dear customer, the information yada yaa");
}
...
Если это какое-то состояние инвалида в приложении:
public void sendCustomerInformation( Customer c , OptionalMessage optionalMessage ) {
if( cusomer == null ) {
// wait a minute, how could... why did.. what?
throw new IllegalStateException("Hey, I got null on sendCustomerInformation and this shouldn't happen");
}
...
Потому что, возможно, приложение отвечает за поддержание этого объекта / параметра в правильной форме.
Заключение
Так что это зависит от сценария, но в общих чертах, исключение NullPointerException (и большинство исключений RuntimeException) указывают на то, что можно исправить с помощью кода (это ошибка программиста), и вы всегда можете что-то с этим сделать. Бывают случаи, когда вы ничего не можете с этим поделать, лучшее, что вы можете сделать, - это дать ему выскочить.
Надеюсь, это поможет.
См. Также: Исключение, отличное от RuntimeException