Path: utzoo!mnetor!uunet!mcvax!inria!blueberry!shapiro
From: shapiro@blueberry.inria.fr (Marc Shapiro)
Newsgroups: comp.lang.c++
Subject: Re: Exceptions and Destructors
Message-ID: <681@inria.UUCP>
Date: 19 Apr 88 07:53:43 GMT
References: <8180011@eecs.nwu.edu> <352@otc.oz>
Sender: news@inria.UUCP
Lines: 60
Summary: don't do anything in destructors

In article <352@otc.oz> mikem@otc.oz (Mike Mowbray) writes:
>Since there's heaps of talk goign around about exception-handling ....
> [...]
>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.
>[...]
>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...?

I agree totally with these points.  I would also like to add
that you are never assured that the destructor for a certain object
will actually be called: you might exit, abort, call a non-returning
function, or just forget to call delete.

Therefore I think an important programming principle is: NEVER TRUST A
DESTRUCTOR TO BE CALLED.  (Does Unix trust you to "close()" all your files
cleanly?  No way.)

Corollary: NEVER DO ANYTHING IMPORTANT IN A DESTRUCTOR.  The only
sorts of things a destructor should do are "benevolent side-effects",
i.e. things which can benefit performance but won't be a mistake if
not performed, e.g. freeing memory.

Suppose for instance you have an application which creates many
windows.  For each window the application allocates a window object.
The window object constructor tells the window manager to reserve
space for it, and the desctructor tells the window manager to close
(i.e. erase) the window.

Now what if this application gets killed: the window manager must
detect this and delete the corresponding windows.  Conclusion:
it's not worthwile for the window-object destructors to close windows,
it's just duplicating work that the manager has to do anyway.  (If you
want windows to pop up and disappear, add a window::close() operation,
independent of the destructor).

The final problem is that the window manager needs a way to detect
that that the application went away.  This is not easy in today's
operating systems.


						Marc Shapiro

INRIA, B.P. 105, 78153 Le Chesnay Cedex, France.  Tel.: +33 (1) 39-63-53-25
e-mail: shapiro@inria.inria.fr or: ...!mcvax!inria!shapiro

						Marc Shapiro

INRIA, B.P. 105, 78153 Le Chesnay Cedex, France.  Tel.: +33 (1) 39-63-53-25
e-mail: shapiro@inria.inria.fr or: ...!mcvax!inria!shapiro