How is using libraries checking nulls better than getting NPE? [duplicate]

Question

Sometimes I see developers using libraries like Guava’s Preconditions to validate the parameters for nulls in the beginning of a method. How is that different than getting NPE during runtime since a runtime exception occurs in either way?

EDIT: If there are good reasons, then shouldn't developers use libraries for null-check on all methods?

Gargantua

It could be if you check up front you haven't done any work yet, work that you may have to roll back or leave in an inconsistent state were an NPE to be thrown in the middle of said work? – Mustachio

Also, you can throw an exception with at least some meaningful message to the user (at least a lot better than a NullPointerException) – Arsphenamine

null parameter does not always lead to immediate NPE. For example, it can be put to some field or collection and lead to bugs that are hard to investigate – Electroplate

@user1445898 Added a follow-up question based on the responses. Reiterating the question here: if there are good reasons, then shouldn't developers use libraries for null-check on all methods? – Gargantua

@Gargantua It is the same as having 100% unit test coverage - almost always overkill not worth the effort. Most error-reducing techniques (unit testing, defensive programming, code styles etc) have diminishing returns. Programmers should always balance their cost (time spent writing and maintaning excess code) and their profit (time saved fixing bugs). – Electroplate

@raedwald IMO, this question is not a duplicated because the "duplicated question" asks how check for null. This question to ask when and why to check for null. – Gargantua

Answer 1

Some reasons are:

• Prevents code from being run prior to the first time the variable (which could be null) is de-referenced.
• You can have custom error messages, such as "myVar was null, I can't proceed further", or any relevant message which will look better in logs and more easily traceable. A normal NPE would be less readable in logs.
• Readability of code is better (arguably) because a programmer reading this code will realize immediately that these values are expected to be non-null.

Ultimately it's a matter of taste IMO. I have seen programs that are inherently null safe and don't require pre-conditions at all.

Denten

No-one should underestimate the value of custom error messages. – Slowworm

Added a follow-up question based on the responses. Reiterating the question here: if there are good reasons, then shouldn't developers use libraries for null-check on all methods? – Gargantua

In general, only methods which are going to be used "externally" demand argument checks. Once you're inside code you control, especially private methods, you can often prove to yourself that the arguments must be non-null (and of course correct in other relevant ways). My general rule is that any public method or constructor always gets argument checking. – Taille

Answer 2

There are various reasons. One big one, as mentioned in the comments, is to get the checking done up front before any work is done. It's also not uncommon for a method to have a code path in which a specific parameter is never dereferenced, in which case without upfront checking, invalid calls to the method may sometimes not produce an exception. The goal is to ensure they always produce an exception so that the bug is caught immediately. That said, I don't necessarily use checkNotNull if I'm going to immediately dereference the parameter on the next line or something.

There's also the case of constructors, where you want to checkNotNull before assigning a parameter to a field, but I don't think that's what you're talking about since you're talking about methods where the parameter will be used anyway.

Limn

One of my favorite software principles is "Fail early, fail loud". Catching and reporting a bad argument as soon as possible makes diagnosis and debugging much easier. – Taille