stuarth@argo.csis.dit.csiro.au (Stuart Hungerford) (05/27/91)
This is a summary of the responses I received to my request for advice
on error handling strategies in C++ and other OOP's. Thanks to those who
replied.
Stuart
--------------------------Summary------------------------------
From: dsouza%cadillac.cad.mcc.com@mcc.com (Desmond Dsouza)
Subject: Wanted: Your error handling strategies for C++ and OOPL's
Look at this paper:
Exception Handling without Language Extensions
William Miller
USENIX C++ Conference, Oct. 1988
Portable scheme. Can easily be extended to deal with
a hierarchy of exception types (if you implement run-time
type checking on exception objects), resumptive model
of exceptions (by allowing handlers to attempt a repair()
before actually invoking unwind destructors), etc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From @RELAY.PRIME.COM:williams@scott Tue May 14 03:59:16 1991
Subject: Errors in C++
We implement our our type machinery on top of C++, in part by using some of
the mechanism available in the NIH library. (This helps with a number of
things, including variable-sized structures and streaming of objects over
TCP/IP connections.) Our approach to errors is just to propagate them
through the data. This is the way Lotus 1-2-3 handles it; for instance:
x = 1/0
y = x + 1
would result in both x and y being assigned the pseduo-value "error".
In Smalltalk it's possible to have a close relationship between types in
the application domain (= Real World (tm)) and the implementation language,
but I just don't think that that is true in C++. If you're not doing it
already, you should definitely consider building your own type machinery.
Also, have you looked at the NIH library?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: Thomas Wang <thomasw@hpcupt1.cup.hp.com>
Subject: Re: Wanted: Your error handling strategies for C++ and OOPL's
There are two parts to exception handling. The first part is the logging
of error information. The second is jumping out to an error handler.
The most common scheme is the 'nested error handler' scheme, where you
can have a stack of error handlers. The handlers themselves are quite
easy to code. You can use setjmp / longjmp to implement them.
With C++, there is a problem dealing with destructors. When jumping out
of a scope, using longjmp() will cause the destructors to be not called.
Actually, the underlying problem is that some C++ objects have undefined
life time. The jumping out mechanism cannot be smart enough to know if
objects in the enclosing scope should be deleted or not. We need a
garbage collector to do this correctly.
One possible solution: you might use Boehm's collector, in addition to not
use the destructor feature of C++.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------+
| Internet : stuarth@csis.dit.csiro.au | |
| Voice : +61-6-2750941 | _--_|\ |
| Fax : +61-6-2571052 | / \ |
| Postal : CSIRO Division of Information Technology, | \_.--._/ |
| GPO Box 664, Canberra ACT 2601 | v |
| AUSTRALIA | |
+---------------------------------------------------------------------------+