Proposal: Elvis and Other Null-Safe Operators (original) (raw)

Jeremy Manson jeremy.manson at gmail.com
Sun Mar 1 09:48:53 PST 2009

The principle perceived disadvantage, however, is that it encourages, rather than discourages, the use of null values in APIs.

I would think that the principle disadvantage would be not that it encourages use of null values (which, as you point out, is fine in some contexts), but that it encourages programmers not to think about what happens when there is a null value. I can easily imagine programmers using this all of the time without thinking about it, and then being surprised when a null ends up in the wrong place and not knowing how it got there. Even with a simple example:

public String someFunction(String a, String b) { String s = a?.concat("foo"); String t = b?.concat(a); return myHashMap?.get(t); }

Now, someFunction returns null. Is it because a was null? Or b was null? Or myHashMap was null? Or there was no mapping for t in myHashMap?

I then imagine this spread out over 70 methods and 10,000 LOC, and realize that problems will be much harder to track down.

In short, the danger is that lazy programmers start using this construct when getting a null value actually matters. I'd much rather stick with fail-fast NPEs for this case. If you want to cut down on extraneous if-testing, I would use JSR-305's Nullity annotations instead.

Jeremy

More information about the coin-dev mailing list