The Old Joel on Software Forum: Part 4 (of 5) - Another take on the exceptiobs vs error codes

Another take on the exceptiobs vs error codes

some more words for thought

http://directorblue.blogspot.com/2004/05/return-codes-vs.html

new_one
Thursday, May 20, 2004

Hmmm yet another pointless blog with an article masquerading as insight.

thanks for that
Thursday, May 20, 2004

At least he had sufficient confidence to sign his name to his thoughts and allow anyone on the internet to rebut them. How about you?

Chris Winters
Thursday, May 20, 2004

If you seriously think that because you put some characters in the field marked "Email:" that is makes you some how "better" or "less anonymous", you are sadly and delusionally wrong.

Anon-y-mous Cow-ard
Friday, May 21, 2004

but what is the problem? To begin with, people who would declare the exception in the caller of exception-throwing method (or catch it and do nothing) are the same people who would not check the return codes. Is the argument about teaching coding discipline, or about which approach fosters that discipline more? In the latter case, I do not think error codes are that much better; after all, many times you are still manually propagating the error up the call stack in the way exceptions do automatically. E.g., try to write something to a file, oops, the call to open a file returned an error - so we just return an error in turn.

Yeah, I know I should've been there in time for the original heated argument, but I wasn't -- though I read all of it.

GG
Friday, May 21, 2004

I coded C with error codes in my last job, and Java with exceptions in my current jobs, and there's no doubt in my mind that the exceptions are vastly superior.

99% of the my methods don't need to do any sort of cleanup, such as closing a database, when something goes wrong. The code is much cleaner and more readable with exceptions. And for the remaining 1% of my code, exceptions are just as straightforward as error codes.

And the article's author is clueless when he says that readability is less imporant than correctness. More readable code is more likely to be correct, since complex code tends to hide subtle bugs and is easier to break when someone modifies the code.

Julian
Friday, May 21, 2004

Funny, I asked Andrei Alexandresu this at the ACCU England conference, and he finally admitted that he didn't know when to use exceptions and when to use return values. He seemed to be moving more toward return values, which I can hardly believe, but tend to agree with.

christopher baus (www.baus.net)
Friday, May 21, 2004

Some thoughts..
- Joel probably should have emphasized multiple return vals more, or maybe his readers should've taken it more seriously. I think people should be able to program in whatever style they wish, but they need the tools to do it well.

- Goto was /never/ considered harmful. Dijkstra's paper was altered from "A Case Against the Goto Statement" by the editor. He explained how it "in later years would be frequently referenced, regrettably, however, often by authors who had seen no more of it than its title."

Tayssir John Gabbour
Friday, May 21, 2004

They do different things.

If your pants are on fire and you need to either take them off or douse them with water then this is an exceptional event calling for exceptional behaviour. Taking your kegs off is not generally part of walking around behaviour.

If someone gives you short change at the shop its perfectly normal behaviour, if an abnormal result. Your general behaviour for handling shopping is primed for such events. It might be exceptional but it is not strange and other worldly.

In other words, exceptions are out of context, error codes (actually I prefer the term status codes, errors are a subset of status), are in context.

Simon Lucy
Friday, May 21, 2004

And here is my little argument for exceptions:
Exceptions don't solve anything by itself - you have exactly the same problems in both cases, and you have to deal with them one way or another. But when I'm using exceptions, my mind is free of thinking about such a fruitless thoughts, like where the error code should be returned (by the method itself, first argument, or last?), how should it look (-n for errors, 0 for success, and +n for warnings?), and how to pass additional information to it (put it in global data? or maybe return an object instead?). When I'm using exceptions, I don't have to think what returned error code means, and where to look for it: exception names are self-explanatory, and I can check type of returned object. My methods do exaclty what they are intended to do: the "getAttribute()" method will return an attribute, not a magic error code.
This way all is getting cleaner, simpler and faster. And it canot be "harmful", you know.

Radosław Maruszewski
Friday, May 21, 2004

In Symbian they make careful separation.

Status codes are used to when a action can be expected to fail, e.g. openning a file. You should always examine the return code and act appropriately.

Exceptions (technically Symbian has it's own setjmp equiv called Leave) are used for occasional out-of-context stuff like out-of-memory. And there is an automatic mechanism for cleaning up heap temporaries (thing autoptrs) to go with it.

i like i
Friday, May 21, 2004

I find it rather surprising that Alexandrescu of all people is in favor of return codes. He did after all come up with the ScopeGuard idiom which is a perfect way to make c++ code exception safe using RAII..
I find myself using exceptions more and more, with my c++ code that is, and I think that with the way I design classes today, they're at least somewhat unavoidable.
What else do you do, for instance, if a constructor fails? Leave a zombie object? Yuk.

Kristian Dupont
Friday, May 21, 2004

Whatever works....If you want to use return codes, fine. But make certain that you actually *do* something with them and not just bury them which is what I see happen in a large percentage of code that I audit.

Of course, you can bury exceptions too, but I don't see that as nearly as often as I see:

int result=foo();
// Continue processing, completely oblivious of what value is in result.

Oh...The database didn't open. Sure which we had bothered to check that return code before we attempting to run that query. That's ok...we'll just bury that return code too while the user sits there with a dumb look on their face wondering why the program isn't doing anything.

Mark Hoffman
Friday, May 21, 2004

Good point Mark.

That is one reason why I prefer exceptions over return codes ... with exceptions you have to deliberately suppress them if you want to do nothing, whereas with return codes it is too easy to just ignorantly assume success and continue with the next line of code.

Of course, that still doesn't help with the idiots who put a try/catch block around everything and leave the catch block empty. But at least it takes some extra effort to ignore them in that way, as opposed to conveniently ignoring the return code, so it should occur less and is easier to notice.

T. Norman
Saturday, May 22, 2004