TITLE: Initialization and exceptions

PROBLEM: jbn@lulea.trab.se (Johan Bengtsson)

[...] Code reviews should specifally look for functions with
de-initialization but no CATCH block.


RESPONSE: matt@physics16.berkeley.edu (Matt Austern)

I'm afraid I don't understand this comment: I don't see why every
function that does de-initialization must always catch exceptions.
Is there something obvious I'm missing?


RESPONSE: fjh@munta.cs.mu.OZ.AU (Fergus Henderson), 6 Jan 93

Suppose that you have a function that does some de-initialization.
Typically it will look like roughly like this:

	foo() {
		initialization();
		do_something();
		de_initialization();
	}

If an exception is thrown by do_something(), then the initialization
will be performed without the matching de-initialization.  This will
lead to a resource leak.  Either foo() should be rewritten as

	foo() {
		initialization();
		try {
			do_something();
		} catch(...) {
			de_initialization();
			throw;
		}
		de_initialization();
	}

or the "Resource Acquisition is Initialization" idiom should be used.

The only way (imho) of writing reliable, robust, and maintainable code
is to assume that an exception can be thrown by any operation.  Even if
you _know_ that a particular operation won't throw any exceptions, you
should assume that it might, because such knowledge is non-local and
not stable: tomorrow someone will modify the operation in question so
that it _does_ throw exceptions.  So even if foo looks like

	foo() {
		initialization();
		code_that_will_never_throw_any_exceptions();
		de_initialization();
	}

you should treat it like the code above, because future maintenance
may render this assumption incorrect.