Error handling: What's recommended for Class Libraries?

  • Thread starter Thread starter Paul
  • Start date Start date
P

Paul

I've been searching for some general, practical guidelines that
distinguish between when it's the responsibility of the architect to
throw errors, and when it's assumed that catching them is going to be
the responsibility of the app programmer. As somebody who is new to
wearing the "architect" hat I find it confusing to consider throwing
errors that are only going to bubble up to the app if I don't throw them
anyway. Unless there is some secretive black-box thing that I'm doing,
and can add some extra text to the message property then I don't see why
I should bother throwing the error at all.

I'm working with fairly simplistic apps too, and this may be why I'm not
seeing the bigger picture with the way the error handling goes between
libraries and apps.

Besides adding some text to the message (that could indicate a wide
variety of value-added data, I guess), what would be the advantage of
throwing at the class library level? Perhaps one advantage is fixing
problems and not throwing them at all? I have been thinking in terms of
fatal errors that cannot be fixed, something like a "file not found",
something that I consider an error whose handling is the responsibility
of the app progammer.


~Paul
 
My philosophy about this is that:

* framework designers should be allowed to throw and catch.
* application programmers should only be allowed to throw, all the catching
should be done by the framework.

This is based on some assumptions of course:

The first one is that the framework APIs are designed so that exceptions are
ONLY used to signal exceptional conditions. If some "special" condition
needs to be tested by the direct caller immediately after a method call,
then the right way to pass the information to the caller is NOT to throw an
exception, it is to return a status (eventually through an "out" parameter).

The second one is that the framework sets up "catchall" handlers in its
event loop or event dispatching logic (most applications are event driven
these days), before calling the application developer's code. In this
catchall, the framework should report the exception to the user and log it
so that support people can investigate it.

The third piece of the puzzle is to identify a few "strategic" APIs
(ResourceManager.Load is a good example) where you catch low level
exceptions and rethrow them as higher level exceptions with a more civilized
message (something like "cannot load resource xxx"). Here, my intro above
was a bit too strict, application developers should also be allowed to catch
and rethrow like this but I prefered simplifying the picture first.

The fourth piece is to "throw" whenever you detect some abnormal condition
that prevents your method from executing its contract (see B Meyer' "Object
Oriented Software Construction" for a good introduction to "programming by
contract"). So, here a framework designer or an application developper may
throw whenever they detect something wrong.

So, with this approach, you end up with little EH code and a robust
architecture in which every exception is reported and logged correctly.

Sounds like this is the road that you were more or less going to take.

Hope this helps.

Bruno.
 
Many thanks, Bruno. You offered me a pretty comprehensive approach, and
there is a lot of food for thought there. Yes, I was leaning toward
having the framework developer do the bulk of catching, but I wasn't
really sure what the advantages would be. This helps me sort it out. I
certainly don't like the idea of throwing non-exceptional cases as
opposed to out-parameters and the like.

Thanks again.

~Paul
 
Back
Top