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