Re: first sight

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.