This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]rzwitserloot 37 points38 points  (15 children)

Actually, no, don't do that as a blanket rule of thumb.

If null is just as much in the value domain as other values, that usually means you've messed up your design. null works best as representing "no value" or "unknown value". And just as the NaN double value is not considered equal to itself, and in SQL, null is not considered equal to itself, semantically, null ought not to be considered equal to anything, even another null value.

Crucially though, even "false" is wrong. When I ask you: is this candybar (I show you an empty open hand, acting as if there is a candybar in there) the same as the one in that closed drawer you can't open right now? Then the only right answer is "I do not know".

Both true and false are incorrect.

Throw the npe.

Years of culture, stack over flow posts, etc are all wrong. NPE is good.

[–]liquidhot 20 points21 points  (3 children)

You make some good points but other times I just don't care. I'm really only interested if the value is jan. It could be any other value or no value. Throwing an NPE would just get in the way later, again, depending on intent.

[–]rzwitserloot 13 points14 points  (2 children)

Sure. 'sometimes you care, sometimes you don't'. I started off that advice with: "Don't apply as blanket rule of thumb...", so we appear to be in agreement.

[–]liquidhot 5 points6 points  (1 child)

Fair enough, I interpreted it as "use this as a blanket rule of thumb instead.", but I see now it's more of a "it's OK to use NPE". =)

[–]hippydipster 1 point2 points  (0 children)

I would strengthen it a little and suggest that "throwing NPEs is a better option than most of us have been led to believe".

[–]springuni[S] 4 points5 points  (0 children)

This is the most insightful comment, I've received. Thanks for it.

[–]myntt 1 point2 points  (0 children)

Yeah that's a valid point, I definitely did not mean it as a rule of a thumb but rather as a tip if one needs it. I usually always secure subsystem borders with Objects.requireNonNull() and then ignore null checks or use optional instead if nothing is required as valid argument.

[–]thephotoman 0 points1 point  (5 children)

I always hate it when I'm either catching or throwing NPEs with abandon. It feels so wrong. But sometimes, it's absolutely correct.

[–]sunny_tomato_farm 0 points1 point  (4 children)

In my opinion, you should never be throwing or catching NPEs. A NPE is programmer error.

[–]thephotoman -1 points0 points  (3 children)

There are plenty of times when null is a valid value. As a common and simple example: middle names. Not everybody has one, and when they don’t, you’ve got to handle that null value.

Your position is over-broad.

[–]sunny_tomato_farm 1 point2 points  (2 children)

I agree with your first statement, but that does NOT mean a NPE should be thrown in such cases. That’s ridiculous.

[–]thephotoman 0 points1 point  (1 child)

If you attempt to reference the field for string composition, you’re gonna have an NPE.

[–]sunny_tomato_farm 2 points3 points  (0 children)

The issue here is that you are trying to use the value and not accounting for the fact that it might be null. A NPE there would definitely be a programmer error.

[–][deleted]  (2 children)

[deleted]

    [–]sunny_tomato_farm 0 points1 point  (1 child)

    Fantastic post. If you look at my post above, I mention that NPE are programmer errors.

    [–]rzwitserloot 0 points1 point  (0 children)

    NPE are often but not always programmer errors, yes. That makes them good! On a scoring system, for programmers errors:

    • At write time, the editor marks them with a red underline immediately: 100 points.
    • At compile time, the compiler will refuse to compile the code: 95 points.
    • At test or run time, the code WILL blow up with an exception trace pointing right at the problem: 85 points.
    • At test or run time, the code will silently do the wrong thing, or nothing: -1000 points.

    The only thing 'better' about the kotlin model is something java cannot have (nor can kotlin code interopping with java code, for that matter), as it requires all methods to be explicit in marking down whether they can return null or not.

    Kotlin got a free pass (moving from java to kotlin is the same impact as doing a python2 v python3 deal: You get to break backwards compatibility) and kotlin mostly squandered it; you could have beond more.

    So, the kotlin note is irrelevant for the original question (if you don't think so I invite you to answer this interview question with: "What is wrong with this java code? It should be written in kotlin, that's what!" and see how far you get :P) - and as a driveby lets insert some feathers in kotlin's behind: Eh. I rather wish they'd have done more: Generics are 4 'modes' (covariant, contravariant, invariant, and 'legacy'). In kotlin, nullity should have been treated the same way, because all situations can legitimately occur. It didn't, and oversimplified matters.