Comments on: Do Not Litter Your Code With Null Checks

By: Mike G

Mike G — Fri, 05 Dec 2008 19:51:33 +0000

Too many developers use exceptions as part of the normal program flow. They are not designed to be that, they should be used when there is something wrong.

Some methods should return null. Null can be a valid answer depending on what you are doing. I have seen code where the only way I could find out if an object was invalid was to try a method, and the method would work or throw an exception. I had to code a try / catch around the method to trap the silly return value.

By: Steve Py

Steve Py — Wed, 03 Dec 2008 22:33:08 +0000

Just keep in mind that exceptions are just that. The exception, they should not be the norm so any performance concerns around generating stack traces etc. should be m00t. Exceptions should not be used as an indicator of success or failure, that’s what the return value is for. (Which goes into all kinds of fiery territory about when to use return values vs. out parameters but I’m sure that’s been discussed here before.) Simply put for tracking down intermittent issues a useful tool is Break on All errors. As soon as you start using exceptions common-place to indicate “failure”, that tool is basically useless. But that digresses from Null checks…

Having worked on projects where nearly 1/3 of all “bugs” revolve around going through call stacks tracking down root causes for “Object reference not set to an instance of an object.” I’ve come to the conclusion that #null is a twisted, evil time-waster.

By: David Fauber

David Fauber — Wed, 03 Dec 2008 20:14:05 +0000

“I’m not entirely sure what the author really means with this, after all there are probably plenty of developers who consider throwing exceptions when something is wrong instead of letting things blow up as ‘coding defensively’. But if he’s talking about the ‘defensive coding’ variant which often entails returning error codes or null references to avoid exceptions, and then checking for those return values all over your consuming code, then i could not disagree more.”

I think you’re arguing vs a straw man here as that would not be what I’d take code defensively to mean. Exceptions are high overhead because you’re generating a stack trace, and this can easily tie up resources if you’re in production and for some unforeseen reason that exception raising code starts getting pounded, but anyway, that’s a whole other topic.

Coding defensively I would take to mean checking for nulls where having a null passed in would indicate an error state, then throwing the exception immediately. Not returning error codes or nulls which need to be checked for. This is in contrast to not doing said checking, and having try/catch blocks around every place where you’re calling the method.

By: Dew Drop - December 3, 2008 | Alvin Ashcraft's Morning Dew

Dew Drop - December 3, 2008 | Alvin Ashcraft's Morning Dew — Wed, 03 Dec 2008 14:34:40 +0000

[...] Do Not Litter Your Code with Null Checks (Davy Brion) [...]

By: David Starr

David Starr — Tue, 02 Dec 2008 23:11:28 +0000

This is a craft issue and one of balance. Code your classes/methods to behave as you would like them to behave as the caller, IMO.

TDD helps this tremendously, but is most commonly the happy path. I think this is a great argument for testing exception cases in Unit Tests and simply being deliberate about the behavior of your SUT.

By: jdn

jdn — Tue, 02 Dec 2008 21:25:42 +0000

” Hurray! We can go home now! Umm… how bout ‘no you can’t and you deserve an elbow to the face’?”

LOL. I’ll have to remember that one.