Re: Exception handling

On 2009-09-18, Martin T. <0xCDCDCDCD@gmx.at> wrote:


Personally, I look at exceptions as on assert()s that must not get compiled
out. Like, some precondition has been violated that would eventually lead to
catastrophic malfunction of the program (= silently producing wrong results in
the worst case), so it is better to crash the program than to end up with
dubious results.

For example, I never expect the pthread_mutex_lock() call to fail on a properly
initialized mutex. If it does, something is *very* wrong (look in the manpage
for the possible error codes), so I throw an exception. In the debug version,
I have no catch() blocks, so any exception crashes the program leaving me with
a nice core dump for the debugger. If I had to make a ``production'' version
of the application, I would wrap one catch block around main:

int main() try {
} catch(std::exception &e) {
   // report error, save app state
   throw; // still want a core dump
} catch(...) {
   // report less meaningful error, save app state
   throw; // still want a core dump
}

Still no catch() blocks in the rest of the program.

Similarly, I throw exceptions to check other system calls that must not fail,
and from whose failure I cannot recover from, and for cheap pre-/post-condition
checks in those places of the code that I am not confident enough that they do
what they should.

In short: I use exceptions for *unrecoverable* errors, so it's not a big deal
if the program crashes due to an uncaught exception -- it would have crashed
anyway sooner or later, or, even worse, silently produced wrong results. Maybe
there are also other, equally or more useful, approaches to exception-handling,
but they have eluded me too :)

I use assert()s for expensive tests, i.e., those that change the O-class of the
algorithm (e.g. O(1) algorithm can become O(n) because of an assertion), or
those that introduce large (individually defined for any given case) constants
in the algorithm's asymptotic complexity. (For example, I had the case that a
complex series of operations had to result in a sorted sequence before the next
series of operations is performed. So I inserted a call to
assert(is_sorted(...)) before the next series of operations. Expensive, but it
ensures that I do not introduce additional bugs while fixing the code belonging
to the previous operation sequence.)

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]