0

Concerning the holy war question about choosing the proper exception in case of a null argument, I wonder if this choice has any practical consequences. I mean, is there a case when you'd catch a NullPointerException and not IllegalArgumentException, or vice versa, or catch both and handle them differently?


To make it clear: This is definitely not the linked question. I'm not asking what exception to throw... I'm asking if they ever get handled differently. I know that with both being RuntimeExceptions they hardly ever get caught, but sometimes you have to do it.

Community
  • 1
  • 1
maaartinus
  • 44,714
  • 32
  • 161
  • 320
  • It rather depends on why the exception is thrown, no? – Matt Ball Jan 30 '14 at 14:13
  • I have essentially no experience with large real-world systems, but as both of these exceptions will generally only happen if you have a bug, I think you're unlikely to specifically catch either one. – user2357112 Jan 30 '14 at 14:15

3 Answers3

3

The intent of both exceptions is quiet different

NPE - in most scenarios that I can think of it occurs due to programming errors, so should not be handled.

In case of null, NPE should be thrown in a fail fast manner as it affects the trace. For which I personally use Preconditions.checkNotNull(E ref, String message) of Guava.

IAE - This means there that the class did not expect such a value from the caller. There can be scenarios when you can catch that exception and use default value for recovering.

I know that with both being RuntimeExceptions they hardly ever get caught

According to me this is quite a misconception that Runtime exceptions are hardly ever caught. Nowadays APIs are depending more on Runtime exceptions as they want to leave on the caller to decide whether the exception gets caught. Many APIs impose you to catch many exceptions which leads to a lot of pain when you know that exception is never going to occur. You are forced to catch it and leave an empty catch block or better log that it should not occur.

The APIs do however specifically document when a particular exception is meant to occur.

Take an example of Integer.parseInt(String s) which throws NumberFormatException and which is a Runtime exception, in most scenarios when I have used it I always catch it and do some recovery using default values.

Think of the scenario if NumberFormatException would have been a checked exception, and you making a call Integer.parseInt("1"), it is clearly visible that it won't occur but still you will be forced to catch it. Agreed that the example is a hypothetical one, but gets my point through.

Again this is just my opinion based on my experience.

I'm asking if they ever get handled differently.

As I have wrote NPE is not caught in most scenarios, but there are always exceptions. Like suppose there is a part of your system that is kept open for extension for someone else to program and there is NPE in that code and you don't want the upper layers to be affected by it then I catch NPE and remove that component from the system giving proper logs and traces. A concrete example is a pluggable system, I didn't want my whole system to crash due to programming error in a user written plugin. So I caught Exception. This may be a bad example for others but worked for me.

Narendra Pathai
  • 41,187
  • 18
  • 82
  • 120
1

IllegalArgumentException can be caught when sanitizing a user input based on criteria known only in the throwing method. It is a more subjective notion, and therefore I sometime catch it.

null you can always test yourself.

njzk2
  • 38,969
  • 7
  • 69
  • 107
0

I don't think there is any difference from a technical point of view. I'd say stick to a strategy and document it as best as you can. Moreover, these are runtime exceptions, so they are not meant to be caught as they should happen in case of bugs or when a client calls a method/service without providing all the required parameters. Let it crash!

About the holy war question, I do believe NPE should only happen when a client tries to access a variable they think is not null but is, indeed, null and thus never thrown directly. IAE is more appropriate if a client expects a non null value and receives a null from a caller. This is IMO, don't want to take part in the feud.

Giovanni Botta
  • 9,626
  • 5
  • 51
  • 94