Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Coding Standards.  was: a style question
Message-ID: <14503@smoke.brl.mil>
Date: 17 Nov 90 14:13:58 GMT
References: <i7NRs3w163w@phoenix.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 38

In article <i7NRs3w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes:
>   The main advantage to having one exit point is that it is easier to be
>sure any necessary cleanup is performed prior to exit.

A lot of the code in BRL's MUVES project has functions implemented more or
less along the following lines:

bool function( ... ) {
	...
	if ( problem )
		{
		ErSet( CODE_0 );
		goto err_0;
		}
	...
	if ( problem )
		{
		ErSet( CODE_N );
		goto err_n;
		}
	...
	return true;	/* success */

	/* error handling consolidated here: */

    err_n:
	fclose( fp );	/* for example */
	...
    err_0:
	FreeList( tp );	/* for example */
	...
	return false;
	}

The idea is to make sure the sequential actions are unwound in reverse
order when an error occurs.  While there are numerous other methods,
this one has worked rather well in practice.  It is also a good example
of structured use of "goto".