bby@palladium.UUCP (Bob Mastors) (11/10/89)
The following are some things to think about concerning the
design of an exception mechanism for C++.
In Meyer's book, OOSC, he states that it is the responsibility of
all routines in a class to leave the object in a consistent state
before they return to the caller.
Of the routines that have an exception handler what percentage of the
routines use the handler to fix a problem and what percentage use
the handler just to ensure that the object is left in a consistent state?
Should the language for the exception mechanism support preconditions,
asserts and invarients? Or should this be implemented outside of the
language as a layer on top of the exception mechanism.
Can the introduction of the exception mechanism break existing code?
Say you have a class A that uses a class B under cfront 2.0. You upgrade
to cfront 3.0 with exception handling and class B gets modified to
use the exception mechanism. Is it acceptable for class A to break
if it is also not modified to use the exception mechanism? Broken
means a type A object may cause a core dump or may not pass the
exception up to a higher level.
Should the exception mechanism be active or passive? Active means
that when an exception is generated the equivalent of a longjump is
done to the appropriate exception handler. Passive means that the
caller of the routine that generated the exception is only aware
of the exception if an explicit check is done.
If an exception occurs and control is transferred to an exception handler,
is the exception cleared on entry to the handler, or is the exception
cleared only if the handler explicitly clears it.
If a handler fixes up the problem that caused an exception and wants
to repeat the operation, how does it do this? Is there a "retry" keyword
that restarts the routine containing the handler over again? Or is
it up to the handler to call its routine recursivley? Or should the
handler just repeat the code that failed?
How many exception handlers are allowed per routine? The choices are
probably one or n, where n is equal to the number of blocks in the
routine. One handler would certainly make the code easier to read,
but is it sufficent?
What happens if an exception occurs inside of an exception handler?
Is the rest of the code in the handler allowed to execute?
What happens if an exception occurs in a constructor? Should the
constructor leave the object in a reasonable state that allows the
methods or destructor to be called without causing a core dump? Or
should the constructor reset itself so that the destructor does not
need to be called?
How do you prevent collisions in the name space for exceptions?
Is it acceptable for an object to leak memory, or some other resource,
when an exception occurs?
Is an exception something that is not supposed to happen? Or should
the exception mechanism support events that are meant to happen? Such
as keystroke input.
If you read this far and are still interested then check out Meyer's book
called "Object Oriented Software Construction." He has a chapter on
exception handling. Also get Stroustrup & Koenig's paper "Exception
handling for C++" just published in the proceedings of C++ at work '89.
Bob
ps:
You can order the proceedings mentioned above from:
The C++ Report
310 Madison Ave., Suite 503
New York, NY 10017
212-972-7055
$39 plus $10 for overseas mail
I have no connection with the C++ report and hesitate
recomending the proceedings given all the other technical books
that are on my list to buy. But that is were the paper
is published. And if someone said the $39 dollars just
barely covered costs I would not argue with them, but I would
ask them why they don't go ahead and post the contents to
the net.
---
Bob Mastors
Epoch Systems, Marlboro MA (508) 481-3717 (voice)
(508) 485-3241 (fax)
{linus!alliant, harvard!cfisun}!palladium!bby