Poor sod ..

JoelOnSoftware used to be a really good read. Lately, it's been JoelOnJoel, and throw in some of that 1990s programming stuff just to sound technical. Take today's post as an example:

... I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's:

1. They are invisible in the source code. Looking at a block of code, including functions which may or may not throw exceptions, there is no way to see which exceptions might be thrown and from where. This means that even careful code inspection doesn't reveal potential bugs.

2. They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function. Every time you call a function that can raise an exception and don't catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn't think about.

A better alternative is to have your functions return error values when things go wrong, and to deal with these explicitly, no matter how verbose it might be.

I'm speechless. (Well, that's not very likely. What I mean is that this guy is waxing clueless.) Let me start by saying that I like his rationale: Unknowns can lead to bugs, and by making everything known, bugs can be eliminated. I mean, come on, who doesn't want to exterminate entire families of bugs? I've coded reams of C++ code that did exactly Joel suggests, and he's right, being extra-anal with immediate error handling and well designed unambiguous return values does improve the quality of code. In C++.

Of course, maybe Joel is still coding in C++. Obviously, he's not coding in Java, which he likes to talk about in the article. The thing is, in Java, which is what most new projects are being built in (or it's cousin C# for Windows shops), using return values as he describes is an anathema. Reading his blog, I feel like how I did back when C programmers were trying to tell me how to build COM applications in C++ .. in fact, his code examples look like they are straight out of a "How to Code Windows NT 3.1 applications in C" book and would even make good examples for "Writing Solid Code" -- if it hadn't already been written 10 years ago, that is.

I wouldn't have had a problem with what he wrote, if he could have stopped with "C/C++", but he somehow assumes that since Java (also C#) generally shares the C/C++ syntax, that it must suffer from the same weaknesses. Java was designed from the ground up around good exception handling; it's not a glue-on long-jump afterthought. With these modern languages, exceptions are generally exceptional, which is to say that just about any line of code can theoretically throw an exception (I use the term "exception" in the loose sense that includes an "error" in Java), and the behavior of exceptions is very well defined and fairly logical.

Even catching all possible exceptions where they occur in Java is basically impossible .. by design. It reflects reality, instead of (as in C++) the assembly code that the source code generates. Furthermore, in Java, if you will purposefully throw something, you get to declare that exception as a checked exception, largely mitigating one of Joel's other concerns. (In C#, there are no checked exceptions, but you can still write comments saying what your code throws, which is a reasonable trade-off for being able to build Windows Forms in COBOL.)

So do yourself a favor: If you're coding in Java or C#, ignore his advice. The 90s are over and have been for a couple years. I don't like to have to explain OO to C coders (they still say "What's the big deal? I can do all that with structs and function pointers!") and I don't want to explain modern exception handling to people polluting their code with reams of brittle "if" statements under some delusion that they are actually handling exceptional conditions.