[Tutor] Exceptions vs. Status Codes

Kent Johnson kent37 at tds.net
Wed Dec 7 14:01:54 CET 2005

wkranec at gmail.com wrote:
> Hi,
> I have a general question regarding programming style which may or may
> not have an answer.  Is it a better practice to have a function raise
> an exception on error, so that the error can be caught; or return a
> status code indicating that the function was unsuccessful?

Hmm, this is a harder question than I thought :-)

My first response was to say, in general using exceptions to indicate
errors is more useful. But after a little reflection I realized that I
use status codes of a sort quite a bit as well.

Long ago and far away I programmed for Mac OS 9. This OS was meticulous
about returning status codes from every system call. Well-written client
code had to be equally meticulous about checking the codes and returning
them back to callers. As a result, any function that used the OS would
return an error code; actual return values would be returned by
reference in a parameter to the function. Client code ended up looking
like this:

int errno;
if (errno=doSomethingImportant() != noError)
   return errno;

int param;
if (errno=getParameter(&param) != noError)
   return errno;

if (errno=doSomethingWithParam(param) != noError)
   return errno;

etc. As you can see, the code is dominated by the error handling, even
though all it does is return the error codes to the caller, it doesn't
actually handle any errors.

The same code written using exceptions would be stripped of all the
error handling code, like this:

int param = getParameter();

This is *far* more readable and much easier to write.

Also consider the consequences of forgetting to check an error code.
Suppose that due to ignorance or lazinesss the first code had been
written like the second, ignoring the error codes. If an error does
occur, it won't be recognized until some secondary failure occurs; maybe
  doSomethingWithParam() will crash catastrophically because
doSomethingImportant() didn't suceed.

The second code doesn't have to do anything special to handle
exceptions; at some higher level in the code it can catch exceptions and
deal with them. If there is no exception handler an uncaught exception
will terminate the program with a stack trace showing the location of
the error.

On the other hand, when a function is returning a value and there is a
reasonable sentinal value for failure (such as None) and the caller
can't reasonably proceed without the returned value, I will sometimes
return None to signify failure instead of raising an exception.

For example, suppose our program needs to load a Foo resource that may 
be found in one of two places. We have functions getFooFromA() and 
getFooFromB() that return either a Foo or None. Client code is simple:

foo = getFooFromA()
if foo is None:
   foo = getFooFromB()
if foo is None:
   raise FooNotFoundError

If the getFooFromX() functions raised FooNotFoundError themselves, the 
client code would be

   foo = getFooFromA()
except FooNotFoundError:
   foo = getFooFromB()

Hmm, not a very convincing example! Maybe I should be using exceptions 
more :-)


More information about the Tutor mailing list