Doug Ross @ Journal

Exceptions vs. Return Codes, part 912

Picture credit: Congreve
Hee hee. Joel's at it again, raising cain in the age-old return-codes versus exceptions argument. Personally, I think it's case-closed for return codes when both Raymond Chen and Joel Spolsky weigh in that exceptions are hazardous, to say the least. But, hey, I'll throw in my two cents (*sigh*, again).

First, let's see what Joel has to say in his latest missive.

Here’s the thing with exceptions... Your eyes learn to see wrong things, as long as there is something to see, and this prevents bugs. In order to make code really, really robust, when you code-review it, you need to have coding conventions that allow collocation. In other words, the more information about what code is doing is located right in front of your eyes, the better a job you’ll do at finding the mistakes. When you have code that says dosomething(); cleanup(); ...your eyes tell you, what’s wrong with that? We always clean up! But the possibility that dosomething might throw an exception means that cleanup might not get called. And that’s easily fixable, using finally or whatnot, but that’s not my point: my point is that the only way to know that cleanup is definitely called is to investigate the entire call tree of dosomething to see if there’s anything in there, anywhere, which can throw an exception, and that’s ok, and there are things like checked exceptions to make it less painful, but the real point is that exceptions eliminate collocation. You have to look somewhere else to answer a question of whether code is doing the right thing, so you’re not able to take advantage of your eye’s built-in ability to learn to see wrong code, because there’s nothing to see.

It's worth repeating the highlighted sentence, because it's true no matter what the pro-exception crowd says: You have to look somewhere else to answer a question of whether code is doing the right thing. Because there's nothing to see.

And that is why you will never be permitted to rely on an exception-based infrastructure if you write mission-critical code. There's no argument about that. None. If you write code for an OS, the FAA, NASA, a database engine, or a nuclear reactor, or any other sphincter-clenching application*, you will not be permitted to rely upon exceptions. Period.

* Defined as any application that, the first time you run it in a production environment, causes: (a) your blood pressure to soar to double its normal levels, (b) you to break out in a cold sweat, or (c) under extreme circumstances, forces you to exert conscious control over certain bodily orifices.

Quick summary: we won't be able to use exceptions if we're writing code for Joel's proverbial open-heart-surgery circular saw. By the way, if you don't agree with this contention, please take a close look at mission-critical software certification specs like DO-178B. Then get back to me.

The reason exceptions are verboten is simple: the code can't be reviewed and validated in any contained fashion.

And now that we've established that exceptions are forbidden in the adult world, I have a question for exception aficionados:

Where do you draw the line between mission-critical and non-mission-critical software?

I'd just like some guidance here: when is it okay to go for anything less than bullet-proof code? What are the rules for delineating between mission-critical and non-mission-critical?

Update: In the comments area, Gil wrote the following. I thought it was worth calling out, for obvious reasons:

I think you've already provided the most useful definition possible of mission-critical software: any software for which it's required to meet an existing standard of mission-critical reliability, like DO-178B or an equivalent. It wouldn't surprise me at all to find that most, if not all, such standards, don't mention or explicitly reject exceptions. This isn't surprising since such standards tend to be very conservative and to rely on time-tested best practices, for the same reason that the chips in the space shuttle are 486s. The point I think you're getting at is that even pro-exception coders won't use exceptions in life-threatening situations; by getting them to draw a line, they're implicitly accepting that exceptions are not a good coding practice, to be followed by the 2 in the 1-2 punch of "if they're not a good coding practice when lives are at stake, why would they be considered good when the software is less than life-threatening? Exceptions are generally bad, and should never be used. QED." The reason no ones drawing the line you're asking them to draw is because they recognize the dilemma you're presenting and are refusing to accept the initial premise.

Exactly.

Joel: Raising cain