The Old Joel on Software Forum: Part 3 (of 5) - Exceptions considered harmful???

Exceptions considered harmful???

Joel's points:

> 1. They are invisible in the source code.

Well yes, that's the point. Exceptions let you handle the problem with the function best placed to handle it and not everywhere like Joel want's to.

The issue seems to come from a "anything could be happening here" point of view, however in my experience quite the reverse is true; by catching everything you can be much more sure that nothing has gone wrong. In Java even null pointers and array index error don't get past a good catch.

>2. They create too many possible exit points

Maybe in C/C++ but in Java/.Net there is a finally that means you can be sure where you are exiting.

However there is one really huge hole in the article at least as far as Java goes. The article says "In C/C++/Java style languages one way you can handle errors is to use the real return value for a result status, and if you have anything you want to return, use an OUT parameter to do that."
Not in Java you can't. Java doesn't have OUT parameters.

Hmmmmmm.

Joe Walker
Tuesday, October 14, 2003

Gotta disagree with Joel on this one. For me the true value of C++ exceptions is the orderly destruction of automatic objects. The need for cleanup code is vastly reduced, if not eliminated. This assumes, of course, that you have a good library of smart classes lying around.

One thing that bugs me about .NET and Java is that they both sacrifice this aspect of exceptions. The advantages of the stack unwinding mechanism are greatly diminished when there are no automatic objects on the stack doing useful work as they go out of scope.

On the other hand, things would be much better if most C++ compilers enforced "throw" semantics in function and method signatures.

Sven G. Ali
Tuesday, October 14, 2003

>Not in Java you can't. Java doesn't have OUT parameters.
<

But I am shure that Java passes objects by reference. There's your out parameters, as public fields on an object created for the purpose.

Thomas Eyde
Tuesday, October 14, 2003

Having 3 lines of code blossom into 48 is just life?

If I beleived this to be true, then I'd change my career tommorrow.

Ged Byrne
Tuesday, October 14, 2003

Hmm, that's just about what I was going to say.

Maybe the "superstars" at Fog Creek can read and write each other's 48 line functions at the drop of the hat without misunderstanding anything, but round here that sure ain't going to happen.

Better Than Being Unemployed...
Tuesday, October 14, 2003

First: lines of code is a destructive way to judge the quality of your programmers or programs.

Second: I know what Joel's talking about. I had a bug hidden by exception handling (in VB 6.0 of all things). There was an "on error goto" in an outer function, and some brainiac decided that the errors in that function were no big deal, so the "catch" block essentially ignored the errors (resume next in VB-speak). An inner function had a problem and raised an exception, the inner function didn't have any error handling code of its' own, so the outer function caught it...and ignored it. It showed up as bizarre behavior in the UI in some cases.

Tracking down this bug reminded me of tracking down similar problems in C a dozen years ago. They were usually related to wild pointers in C.

If all of our functions looked like:

void foo()
{
try {
// put your code here.
}
catch (exception e) {
// put your error handling here
}
finally {
// put your cleanup code here.
}
} // foo

we won't get exceptions going wild. Is it worth it? Maybe. Where it goes wrong (for me) is when not all functions include the try/catch/finally.

P.S. I have had far fewer instances of exception-handling related bugs than I used to have with wild pointers.

Jim Grinsfelder
Tuesday, October 14, 2003

"I don't like exceptions because, this one time, at band camp, someone did something weird, and it seemed wrong, and so I just said 'no more'."

You realize how silly the argument sounds when boiled down, right? You're not going to use a language feature because one time, a co-worker wrote a bit of buggy code?

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, October 14, 2003

What happens when someone adds 49th error
yet that error would be handled pretty much
like the other 48?

You have just introduced an update anomaly into
your code for zero benifit that i can see.

Actually, i never did see a concrete reason for
his position.

son of parnas
Tuesday, October 14, 2003

Jim,

I'm not talking about lines of code, I'm talking about readability. I like code to say what it does.

Remember that VB doesn't really have exceptions.

An exception would provide a stack trace, which VB lacks. In your example the developer should have used err.raise err.number, , "ThisFunciton() - " & err.description. Then your strange error would have been easy to trace.

With proper exceptions you would have none of this. The functionality would be provided by default instead of cluttering up your code.

If your coder had written his function without any consideration for error handling a langauge like Java, which has full exception support, would have caught the error and then provided a stack trace showing the path to the problems source. This would have saved you a lot of time.

If Joel's method had been used then the error returned would have been ignored, exactly the same result as using Resume Next in VB.

In fact, it is even worse that VB because at least the coder had to go out of their way to add the Resume Next. Using the return value has this behaviour by default.

Ged Byrne
Tuesday, October 14, 2003