|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2007-09-15 08:29:24
on Thu Sep 13 2007, Howard Hinnant <hinnant-AT-twcny.rr.com> wrote:
> Hello,
>
> I am requesting comments, both for and against a "sticky exception".
> A sticky exception is one in which once thrown, is very hard to catch
> and handle, without an implicit rethrow. This represents some
> condition which the thrower believes is sufficiently severe that the
> application (or thread) should clean up resources, but not be allowed
> to continue, even with a catch (...) which does not rethrow.
The only purpose I have ever heard for such a thing would be to handle
programming and critical data integrity errors (which in practice are
due to programming errors). Exeptions are for *recoverable* conditions.
I'm strongly against a sticky exception unless there's a way to label
particular cleanups as "critical" and have only those executed when a
sticky exception is thrown. Most cleanups are noncritical, and in the
presence of integrity problems, can cause problems and interfere with
the critical recovery actions that you really do want to execute.
Furthermore, it tends to reinforce the misconception that exceptions
are a good way to handle nonrecoverable conditions.
Frankly there are probably better ways to handle this than by throwing
a special exception. Critical cleanups could be
registered/unregistered as atexit() actions.
Did I mention recently that turning a logic error into an exception is
a bad idea (http://tinyurl.com/2ph58t) and we have no programming
model for handling it?
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk