Timeline for How do I avoid checking for nulls in Java?
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 10, 2023 at 10:55 | comment | added | Paul | Agree with @luis.espinal on the differential uses of NPE and IAE. However, this suggests - to me at least - that Java is really lacking a NullArgumentException as a subclass of IllegalArgumentException. | |
| May 7, 2017 at 21:51 | comment | added | Radiodef | Throwing NullPointerException is the Java convention. See e.g. Objects.requireNonNull which is "primarily for doing parameter validation in methods and constructors" and throws NullPointerException. There is also simply the doc for NullPointerException which states that "applications should throw instances of this class to indicate other illegal uses of the null object". | |
| Aug 12, 2016 at 17:33 | comment | added | luis.espinal | 2/2 - That is, a NPE tells me there is a yet-undocumented null bug within the method (or within the methods it calls) or that there is a null precondition that we have not coded for. An illegal argument exception tells there is a bug outside of this method lying somewhere along the call chain that leads to the current method. Sticking to this pattern (within reason obviously), it does lead to faster root-cause analysis of errors (specially the nasty, intertwined ones.) | |
| Aug 12, 2016 at 17:28 | comment | added | luis.espinal | 1/2 I have to agree that a IllegalArgumentException is better than a plain-vanilla NPE for these type of situations. I see a NPE as an indication that somewhere in the code, something unsafely de-referenced an expression that happened to be null (assuming all known and declared preconditions and invariants were met). An illegal argument exception OTH tells me a well-known precondition or invariant was not met. | |
| S Jul 19, 2016 at 9:02 | history | edited | River | CC BY-SA 3.0 | added 26 characters in body |
| Jul 19, 2016 at 8:32 | review | Suggested edits | |||
| S Jul 19, 2016 at 9:02 | |||||
| May 13, 2015 at 2:01 | comment | added | Michael Plautz | @Axel the whole point of using anything other than RuntimeException is the descriptiveness of the Exception. Why IllegalArgumentException over NullPointerException? Because when you are debugging an exception caused by this, the IllegalArgumentException is abundantly more obvious, especially when you put a message on it. This especially applies to enterprise applications when NullPointerExceptions creep up (yes, these happen in enterprise applications). In this same example, the programmer may not have control over whether or not assertions get processed by the JVM. | |
| Jun 13, 2013 at 23:16 | comment | added | corsiKa | @myplacedk I think it does make sense to have a different exception for null values passed in that from improper values passed in. The two are usually results of different types of programming errors. Null values usually arise from some required computation not happening, while other problems usually arise from required computations being incorrect. | |
| Apr 20, 2013 at 23:35 | comment | added | Thorbjørn Ravn Andersen | throw new IllegalArgumentException("object==null") | |
| Apr 8, 2013 at 0:39 | comment | added | fgb | A security hole? The JDK is full of code like this. If you don't want the user to see stacktraces, then just disable them. No one implied that the behaviour is not documented. MySQL is written in C where dereferencing null pointers is undefined behaviour, nothing like throwing an exception. | |
| Sep 7, 2012 at 18:23 | comment | added | Visionary Software Solutions | "A null parameter is usually just "a general error in programming" and not an application/API specific constraint." Naive. You can use this as a security hole to DoS or attempt to gain stacktrace info (if such information is not supressed). osvdb.org/show/osvdb/67379 If your API is public and you don't explicitly define the boundaries you accept--both through API docs and whatever tools you can use to ensure validity of the contract-- the caller's free to do whatever they want. You are the one who didn't program right then, not the caller. | |
| Dec 3, 2011 at 9:54 | comment | added | charstar | I agree with @Axel in that IllegalArgumentException implies (as I use it anyway) that a precondition for the argument does not hold as it pertains to a constraint on the parameter. A null parameter is usually just "a general error in programming" and not an application/API specific constraint. To maintain a defensive fail-fast strategy, there's nothing stopping anyone for checking for a null and throwing a NullPointerException... which exactly conveys what happened, namely, "you didn't program it right" :) | |
| Oct 21, 2011 at 9:02 | history | made wiki | Post Made Community Wiki by jeha | ||
| Aug 22, 2011 at 11:20 | comment | added | Axel | Yes, I agree to fail-fast-principle, but in the example given above, the value is not passed on, but is the object on which a method shall be called. So it fails equallys fast, and adding a null check just to throw an exception that would be thrown anyway at the same time and place doesn't seem to make debugging any easier. | |
| Aug 15, 2011 at 12:26 | comment | added | myplacedk | It's unlikely that every other value than null is acceptable. You could have IllegalArgumentException, OutOfRageException etc etc. Sometimes this makes sense. Other times you end up creating a lot of exception classes that doesn't add any value, then you just use IllegalArgumentException. It doesn't makes sense to have one exception for null-input, and another one for everything else. | |
| Aug 9, 2011 at 16:47 | comment | added | Axel | What's the point in throwing IllegalArgumentException? I think NullPointerException would be clearer, and that would also be thrown if you don't do the null-check yourself. I'd either use assert or nothing at all. | |
| Feb 6, 2011 at 0:29 | review | Suggested edits | |||
| Feb 6, 2011 at 0:36 | |||||
| Nov 7, 2008 at 9:27 | history | answered | myplacedk | CC BY-SA 2.5 |