|
Boost : |
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2008-07-29 12:10:46
Emil Dotchevski wrote:
> Throwing an exception doesn't necessarily indicate abnormality, in
> fact the program might rely on the exception to operate properly (for
> example, if you're processing a sequence of files, you might want to
> catch(eof &) and open the next file to be processed.)
That doesn't sound like a good idea, given how exceptions are
implemented: a fast normal execution path and a slow recovery path.
They indicate erroneous situations which you can live with. Something
bad happened, but you can live with it and recover from it.
The most usual case is failure to acquire a resource. They cannot be
disabled due to the fact you cannot predict without running the program
whether the situation will occur or not.
Here is my opinion about the rest:
Runtime asserts indicate conditions and invariants that were not
fulfilled, that is to say a promise that was not fulfilled by the
programmer, or a bug. So they're really programming errors.
They're only useful for debug builds, even though fairly often
exceptions are used for cases that ought to be runtime asserts, which is
bad IMO (Java throws when dereferencing a null pointer, numerous Boost
utilities throw when used while being empty...)
Static asserts is similar to runtime assert, except it checks a
compile-time property. It's really the same thing, except that usually
people do not bother to disable them outside of debug builds, since they
only occur at compile-time.
Both kinds of asserts are very useful for testing the validity of a
program. Static asserts especially, since they do not require a specific
dynamic state to be reached.
The difference between exceptions and asserts are that, while both are
errors, exceptions is a system to report error and asserts is a system
to check that errors do not occur.
So the Error Handling category could be subdivided in Error Reporting
(which would also contain error codes and logging) and Error Checking
(which would also contain the testing framework).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk