Path: utzoo!mnetor!uunet!munnari!otc!mikem
From: mikem@otc.oz (Mike Mowbray)
Newsgroups: comp.lang.c++
Subject: Exceptions and Destructors
Message-ID: <352@otc.oz>
Date: 8 Apr 88 09:14:50 GMT
References: <8180011@eecs.nwu.edu>
Lines: 47

Since there's heaps of talk goign around about exception-handling ....

We've heard about how when an exception is raised, and a function context
is resumed further back in the stack, appropriate destructors must first
be called for stuff inside intermediate functions which will now not be
returned through.

Problem: this means that all classes must be designed so that their
	 destructors are callable at any instant and behave correctly, even
	 if you're in the middle of a member function which is adjusting
	 the internal configuration of the class. (For example, a member
	 function which calls another function in which an exception gets
	 raised).

In general, it would seem very demanding to require that destructors for
non-trivial classes be callable at any moment. The destructor writer must
anticipate every possible mis-configuration of the class's internal
structure.

Maybe it's sufficient to adopt a general rule: "In your destructor, assume
that everything is probably corrupted". But then this must also apply to
member functions, since destructors might call them to do part of the
cleanup job. In any case, this is obviously highly error-prone.

The alternative is to ensure that a member function never calls something
else unless the class is already perfectly consistent. But how could an
automated tool assist in detecting this? Maybe the programmer could define
assertions for the class, and the compiler would arrange for them to be
checked before calling any function from within a member function. Sounds
dreadful, doesn't it. Maybe it would be sufficient for the mechanism that
generates the automatic call of destructors to arrange for the assertions
to be checked. But what do you do if the assertion fails?

Another problem area: what if a destructor executes normally to some point,
and then calls a function in which an exeption gets raised, which invokes
the same destructor again in the attempt to clean up properly...?

Thoughts anyone?

			Mike Mowbray
		    Systems Development
			|||| OTC ||

PHONE	(02) 287-4104			  ACSnet:  mikem@otc.oz
FAX	(02) 287-4990			    UUCP:  {uunet,mcvax}!otc.oz!mikem 
SNAIL	OTC, GPO Box 7000		   CSNET:  mikem@otc.oz.au
	Sydney 2001, Australia		    ARPA:  mikem@otc.oz.au