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,
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.
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
here...
Your quotes? Hmm... What do you mean by this?
regards,
alexander.