Re: thread-safety definition

[David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx>]

Dave Butenhof <David.Butenhof@xxxxxx> writes:

>>My point is that one could just as well (and perhaps more justifiably)
>>claim that it's evil to throw any exception that can't be dealt with
>>via a catch(...) block that doesn't rethrow, where that block was
>>designed to handle, say, bad_alloc.**
>>  
>>
> The real issue isn't so much catching without a re-throw, but catching
> and dropping arbitrary exceptions. If you don't claim to know how to
> finalize a bad_alloc error, what business do you have catching it?
> (And since catch(...) is anonymous, even if you could handle it you
> can't identify it.) I'm not convinced there's any rational excuse for
> finalizing bad_alloc unless you know how to free up some memory to
> "cure" the problem that caused it. (Nor would there be any particular
> benefit.) If you can't deal with it, you need to let it propagate to
> someone who can; or to terminate the process.

Let me give you one example.  I used to write desktop application
software.  This software had an undo facility.  The undo mechanism
would store a copy of the portion of the document's original data that
was about to be changed before any change was made.  This arrangement
also allowed any failing operation to be rolled back.  Sometimes the
user would try to do something that would consume more than the
available memory, and sometimes the user would try to do something
that ate up the last bit of disk space, and sometimes an operation
would fail for other reasons.  I could always bring the user back to
the main event loop and fully recover her document's data so she could
try to save it.  The only reason the type of the exception mattered
was that it allowed me to give the user a good error report.  If there
was an exception I couldn't recognize, it would always be better to
say "something I can't identify went wrong; you might want to save
under a different name" than to allow the program to terminate
suddenly, and *definitely* drop the document's data on the floor.  Of
course, I never saw an exception I couldn't identify, but termination
is not always the right answer.

Another real-life example someone once gave me was that of a stage
lighting controller.  It was always better to plow ahead and hope the
issue wasn't serious than to have the stage go suddenly black.

There are surely places where finalizing a catch(...) is wrong, but
there's no blanket rule that applies to all applications.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com