From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-14 18:23:28
<<I mean that it is my understanding that "catch(...) without
throw;" is only valid if I am 100% sure that ALL exceptions
potentially thrown inside try block could be fully handled
by my catch(...) code (or I just terminate the process).
To me, it really does not happen too often, I even do not
remember the last time I wrote "catch(...) without throw;".
Do you have some really good example when it is deadly needed?>>
Yes. Take a desktop editor application of some sort, with plugins, for
example. The application has an undo feature, so the first thing it does
before any editing operation is collect all the data it needs for rollback.
If the operation calls a plugin, the plugin might throw. We can't guarantee
that the plugin writer has translated all exceptions to types we can
recognize (even though we probably told her to), but we do know everything
we need to know in order to perform rollback and get back to a clean state
from which the user can save, print, whatever. A catch(...) is the only way
to be sure we get everything. From there we can tell the user there was an
unrecognized error and continue with the event loop.
Part of the benefit of the basic/strong/nothrow guarantee framework is that
it tends to reveal that correct recovery actions almost never need to depend
on the exception type, and it encourages designs to go that way.
...and I think you've mixed my quotes with bill's so I'll stop here...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk