Beginner to exceptions and status/error codes

Hi - maybe I am missing the point about the exceptions vs return codes argument as I don't have such a deep programming knowledge as other posters, so maybe someone can answer the following question for me:

Wouldn't the best way to handle exceptions vs error codes be to use error codes where you want to trap a specific condition and display an explanatory message to a user, or to perform some sort of action (like retry and operation)
and to use exceptions for unhandled errors in the code (errors you haven't foreseen or haven't got specific handling for)?
Aren't exceptions not going to be the best way to handle errors in specific parts of the code?

Or (and this is probably wrong but I will throw it out there) can you have an exception handler with a big CASE statement that calls specifc code based on the source of the exception?

Maybe Joel was alluding to this in the CopyFiles() example because an exception might just throw the fact there was an error, and might pass through the error message from the OS, but you might want to do a lot more here to handle this case...

Our company is moving to .NET and we don't have a policy on the use of exceptions and I think we probably should...

Pete
Wednesday, October 15, 2003

I'm a fan of using exceptions most anywhere I want to handle errors.  Very useful when coupled with the Command pattern.

That way, I have the individual Command execute through what I call, for lack of a better name, an exception firewall.  Everything's caught there and (optionally) converted to a message for the user.

On Mac/Carbon Nitrogen provides a set of wrapper functions for the Carbon API that throw a different type for every different OSStatus (error code).  That's some useful stuff.

H. Lally Singh
Wednesday, October 15, 2003

"Wouldn't the best way to handle exceptions vs error codes be to use error codes where you want to trap a specific condition and display an explanatory message to a user, or to perform some sort of action (like retry and operation) and to use exceptions for unhandled errors in the code (errors you haven't foreseen or haven't got specific handling for)?"

Bluntly - I think you've missed the point.

Consider the example where an error occurs during a request for a block of memory.  The error is discovered here, in the library, and the user is there, about 20 functions up the stack.  So how shall the two be bridged?

Status codes will work.  Exceptions will work.  Each requires certain adaptations in coding style and therefore have a cost associated with them.

The cost will not be the same in all contexts; it is, in all likelyhood, subjective - or at the very least highly dependent on the experiences of the team.

Danil
Wednesday, October 15, 2003

"The error is discovered here, in the library, and the user is there, about 20 functions up the stack. "

One question to ask is "how did the error make it this far undetected?"  Most often, you can check these things at the interface between your system and users/other systems and reject bad input early-on.

flunky
Wednesday, October 15, 2003

Exceptions and return codes are both messy.  In a perfect world you'd just be able to write code and not think about detecting or handling errors.

But we aren't in a perfect world, so we are forced to choose one form of mess or another.  I find exceptions to be by far the lesser of the two (or more) evils.

T. Norman
Wednesday, October 15, 2003

  Recent Topics

  Fog Creek Home