Comments on: Handling null in Java

By: Jan de Ruiter

Jan de Ruiter — Fri, 16 Apr 2010 15:52:06 +0000

Nice article, but you make the world-with-null values look worse than necessary:
for(Account account: accounts) {
if(account != null) {
totalBalance = totalBalance.add(account.getBalance());
}
}
If the accounts Set is empty, the for loop will not execute its body, so the inner if is not needed:
for(Account account: accounts) {
totalBalance = totalBalance.add(account.getBalance());
}
account will always be set to some non-null value.

By: "null", o una de las maldiciones de Java « AOWS

"null", o una de las maldiciones de Java « AOWS — Thu, 04 Feb 2010 21:48:06 +0000

[...] con valores nulos es, desde siempre, un dolor de muelas muy importante en el mundo de Java. En este artículo de Redcode nos lo recuerdan y proponen algunas de las pocas opciones que [...]

By: Java4Learners

Java4Learners — Thu, 04 Feb 2010 01:44:13 +0000

This is good stuff. Its funny on face of it Java does not support pointers, yet throws a NullPointer Excpetion. A good programmers always make sure they check for null or at least make sure they have a catch block so that this NPE does not go through the stack. Rest all of these methods work to some extent and which one to choose depends on your context one is writing code under.

By: Andrew Velis

Andrew Velis — Wed, 03 Feb 2010 18:13:30 +0000

Great post about using Null’s in Java. I use Groovy at work and love the elvis operator. Now I can’t live without it sometimes. It really is a shame that Java 7 didn’t get the elvis operator.

By: Ara

Ara — Tue, 02 Feb 2010 16:51:58 +0000

If NULL is not a valid value (i.e., always a bug), then the @Nullable and @NotNull annotations make sense. If NULL *is* a valid value, however, then IMHO it is better to handle explicitly in code using IF statements.

The Null object pattern, while convenient, seems dangerous because it can create hard-to-detect bugs. For example, let us assume that, in one case, NULL objects should return a result of NULL (or “unknown person” or “N/A” or…) but in another case they should result in a logic fork. An overworked programmer could easily forget about the logic fork and you get a runtime bug that only shows up in certain situations and whose detection is consequently dependent on having very good testing coverage. And then, assuming you detect it, you have to figure which method has the wrong logic in it.

If you don’t use the Null object pattern, there is a chance you will get NullPointerException, but that’s good because that means the application is fail-fast and you know exactly where you forget to do the check.

By: shunmuga

shunmuga — Tue, 02 Feb 2010 15:44:59 +0000

This is cool post dude nice article!!!

By: royvanrijn

royvanrijn — Tue, 02 Feb 2010 15:31:52 +0000

Adding RuntimeExceptions for all input as check would take quite a bit of effort if you need to do this all over your code. That’s why I still prefer code-by-contract.

Another (probably better) option would be to add assertions (‘assert’ keyword). That is exacly why they created them.

By: phil swenson

phil swenson — Tue, 02 Feb 2010 14:58:10 +0000

Or….

if null is not a valid input (person being null is a bug), first line in the method is

throw new RuntimeException(“person cannot be null!”);

By: Christophe Hamerling

Christophe Hamerling — Tue, 02 Feb 2010 13:38:51 +0000

This is a really nice article, simple and very useful!

By: Stephan Schmidt

Stephan Schmidt — Tue, 02 Feb 2010 10:27:11 +0000

Nice post. You can also use the Option/Maybe monad.

I’ve did a presentation on Null Handling some time ago, which also describes the Option monad.

http://codemonkeyism.com/better-null-handling-strategies-for-java/

And easier usage with the “for” hack in Java:

http://codemonkeyism.com/for-hack-with-option-monad-in-java/

Cheers
Stephan