From: terekhov (terekhov_at_[hidden])
Date: 2002-01-14 19:29:36
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> <<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,
> example. The application has an undo feature, so the first thing it
> before any editing operation is collect all the data it needs for
> If the operation calls a plugin, the plugin might throw. We can't
> that the plugin writer has translated all exceptions to types we can
> recognize (even though we probably told her to), but we do know
> we need to know in order to perform rollback and get back to a
> from which the user can save, print, whatever. A catch(...) is the
> to be sure we get everything. From there we can tell the user there
> unrecognized error and continue with the event loop.
Well, maybe I am too paranoid (or it is just my
poor brain being cloudy) but I would rather
secure the data needed for rollback and would
just restart in a clean new process invoking old
process termination in catch(...) handler. Why
should I trust anything in the old process when
I observe an unexpected plug-in exception? Or
am I missing something? Do you have any
arguments against this approach?
> ...and I think you've mixed my quotes with bill's so I'll stop
Your quotes? Hmm... What do you mean by this?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk