5

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?

Glide
  • 20,235
  • 26
  • 86
  • 135
  • 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? – i_am_jorf Jan 22 '15 at 19:07
  • Also, you can throw an exception with at least some meaningful message to the user (at least a lot better than a NullPointerException) – Mateus Viccari Jan 22 '15 at 19:15
  • 2
    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 – Sergey Alaev Jan 22 '15 at 19:40
  • @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? – Glide Jan 22 '15 at 20:14
  • @Glide 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). – Sergey Alaev Jan 22 '15 at 20:21
  • @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. – Glide Jan 26 '15 at 16:05

2 Answers2

4

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.

ColinD
  • 108,630
  • 30
  • 201
  • 202
  • 1
    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. – isomeme Jan 22 '15 at 21:17
4

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.

Invisible Arrow
  • 4,625
  • 2
  • 23
  • 31
  • 2
    No-one should underestimate the value of custom error messages. – biziclop Jan 22 '15 at 19:24
  • 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? – Glide Jan 22 '15 at 20:14
  • 2
    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. – isomeme Jan 22 '15 at 21:15