Exceptional Design
Raoul Gough asks a question about Hubert Matthews' 'Exceptional Design' article, published in Overload 77 (February 2007):
In the article 'Exceptional Design', Hubert Matthews shows a couple of ways of including error severity information in an exception. Try as I might, I cannot understand why he would even suggest this as a good idea.
Surely the whole point of using exceptions is when non-local recovery is necessary, which means that the throw point cannot possibly know how severe the condition is to the system as a whole. Rather, it is only at the catch point where the severity is knowable. For example, whether a missing file is a warning, severe or fatal depends entirely on what the file is for - a missing config file might well be fatal, but a missing $HOME/.plan probably isn't! Or how about an out of memory error - surely that's a fatal error, right? Well, not necessarily - maybe you can discard some cached data and continue, so in fact it wasn't even really a warning.
So I'm struggling to see what value there is in including severity information in an exception object (whether via its type or its members). I would even go so far as to suggest it leads to thinking about exceptions in the wrong way - rather than reporting the nature of an error, it is trying to pre-determine the 'correct' handling of that error. Maybe Hubert can explain his rationale for this a bit better?
Regards,
Raoul Gough.
Hubert replies:
Exception handling acts in effect like a communications protocol between the point where the exception is thrown and the point where it is caught. Whenever there is a protocol there is coupling through shared knowledge. Think of something like an SMTP email server; both sides have to understand who says what and what the messages mean. In the case of exceptions, the two ends (throw and catch) have to agree on the message format (the exception object) and what information it contains. In some cases it is acceptable to throw an exception without any additional information. In others, a message alone suffices. In both these cases there is a one-way dependency from catch to throw; the throw knows nothing about the catch. In the case where severity information is included (usually where a multi-level recovery strategy is being used) then there is a two-way mutual dependency as the throw now needs to have knowledge about how to indicate what level of error this is. The alternative is to use some form of error type indicator and let the catch decide what to do, which then makes the dependency one way only again. Note that an error level is only advisory; it does not preclude the catch ignoring the level indicator and treating all exceptions as fatal for instance.
This concept of exceptions as an error signalling protocol can be extended to dealing with retries, and alternative or compensating actions. Calls down towards the leaves of the call tree are attempts by the system to achieve some goal and exceptions are out-of-band signals in the reverse direction regarding problems.
Hubert Matthews hubert@oxyware.comSoftware
Consultant http://www.oxyware.com/
C++ Unit Testing Framework (CUTE)
Peter Sommerlad announces a new plugin for the CUTE framework:
Hi all,
In the past, you have shown interest in my C++ Unit Testing Framework, CUTE.
I am sending you this mail to announce the pre-release of an Eclipse Plugin that makes C++ Unit Testing with CUTE almost as easy as Unit Testing for Java with JUnit in Eclipse. (Thanks to Emanuel Graf!)
We created an eclipse plugin for Eclipse CDT (current release) that includes Cute and visualizes test results like the JUnit plugin for Java.
You can install it from its update site (within Eclipse):http://ifs.hsr.ch/cute/updatesite/
More information on my wiki:
NB: the current version of CUTE has some syntactic/cosmetic changes to my original Overload article. The wiki page reflects this already.
More on it at ACCU conference.
Pete Sommerlad
