This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [3.3] Followup to C++ forced unwinding


On 01-May-2003, David Abrahams <dave@boost-consulting.com> wrote:
> There are very few correct programs which can "eat all exceptions and
> plow ahead anyway".  Is it really a design requirement that these
> programs be transplantable *without modification* into an environment
> where they run on a thread *and* where a thread cancellation _request_
> can be assured of terminating them?

Unfortunately there are very few correct programs, period.

Likewise there are also very few robust programs.  As systems get more
complex, robustness is becoming more and more important.  It is in
general not feasible to build complex systems in which no component will
ever fail.  So the only way to ensure robustness is to build systems
that can tolerate failures.

In C, it was easy to build systems which *ignored* failures.
In C++, it is reasonably easy to build systems which *report* failures,
by throwing exceptions when failures occur.  However, in order to
build truly robust systems, it is not enough to just report failures.
The system needs to have some way of tolerating them, by catching
the exceptions and continuing.

Often the places where you can easily recover from exceptions
and continue will be far removed from the places that actually
throw the exceptions.  Furthermore, because of abstraction,
the place which is attempting to recover and continue will
often not know what kinds of errors may occur, since those
will depend on the implementation details of opaque abstractions.

So, when writing robust programs, it is often necessary to catch *all*
exceptions.  Idiom which rely on this, like the "try method A, and if
that doesn't work, try method B" idiom, are crucial to writing truly
robust large-scale complex systems, because they are basically the only
way to avoid the chance of overall system failure scaling linearly with
the number of steps that must be performed.

So, although I agree that there are currently very few _correct_ programs
which contain routines that catch all exceptions, I think that it is
also true to say that there very few _robust_ programs which do NOT contain
such routines.

In short, the idiom which you are trying to deprecate is crucial for
robustness, so it should not be so lightly abandoned!

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]