Comments on: Do Not Litter Your Code With Null Checks

By: Filip Duyck

Filip Duyck — Wed, 03 Dec 2008 18:48:45 +0000

I can’t but agree to that point

By: Davy Brion

Davy Brion — Wed, 03 Dec 2008 18:24:37 +0000

possibly… like i said in the post, i wasn’t entirely sure about what he really meant

but the whole ‘avoid exceptions/use return values’ argument is something i _really_ dislike so i tend to go off when i hear it, or think i hear it

By: Filip Duyck

Filip Duyck — Wed, 03 Dec 2008 18:18:22 +0000

Davy, you definitely misinterpreted the post. As you quote, it says “Code defensively rather than catching exceptions wherever possible” — not “.. rather than throwing exceptions wherever possible”.

This doesn’t nullify your point about return values and null checking, it just makes it a bit irrelevant to the original post.

By: Gilbert Marlowe

Gilbert Marlowe — Wed, 03 Dec 2008 16:04:00 +0000

Sigh… I’ve inherited more than one piece of code that was written (somewhat) defensively. Yes, you should attempt to identify issues and code intelligently to account for and recover from them. BUT, some things are out of your control and some things you’ll miss.

In the case of errors caused by user inputs, never, ever, underestimate the power of a user to do something you hadn’t considered because “it’s stupid” or “nobody will *ever* do that”. Users don’t have the same background/history as you do and won’t make the same assumptions.

If your appplication/system relies on the outside world (whether it’s the internet or a subsystem/input source you don’t directly control), well then prepare for something to go wrong. Mr. Murphy’s law applies to systems of any kind.

The purpose of exceptions is to allow a strongly-typed response to unexpected events. If you know what kind of thing when wrong, you’re in a much better position to respond appropriately, even if that means throwing the exception back up to the caller.

Yes, exceptions are costly, but much, much less costly than aborting the running process or blindly changing database values without notifying the user. Avoid them if it’s reasonable, but rely on them when necessary.

By: Reflective Perspective - Chris Alcock » The Morning Brew #236

Reflective Perspective - Chris Alcock » The Morning Brew #236 — Wed, 03 Dec 2008 10:04:24 +0000

[...] Do Not Litter Your Code With Null Checks – Davy Brion responds to one of the posts linked in yesterday’s edition of the Morning Brew about defensive programming and the throwing of exceptions [...]

By: Davy Brion

Davy Brion — Tue, 02 Dec 2008 20:45:32 +0000

coding defensively against user input is definitely a good thing… but i don’t think his point was to avoid empty catch blocks (which really should be avoided), but that throwing/catching exceptions was costly and should be avoided because of that.

In his examples, the catch blocks are empty because he doesn’t have anything useful to do with them for the tests

By: pho

pho — Tue, 02 Dec 2008 20:40:07 +0000

i think you actually misread the author.
in the examples he never throws exceptions “upwards” or promotes the use of returning useless null references/error codes. the main point he was trying to make is to avoid empty catch blocks, or avoid try/catch blocks in general if you could otherwise simply rewrite it with an if statement.
i quote:
“Code defensively against user input, so that you don’t have to rely on try/catch blocks to deal with exceptions”

and he’s right; everyone has come across some useless empty catch block while browsing a codebase that could have been way more elegantly written with “defensive coding” as he put it