[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python or Perl for a Debian maintainance project?

On Tue, Feb 17, 2004 at 07:21:00PM +0000, Will Newton wrote:
> On Tuesday 17 Feb 2004 4:58 pm, Andrew Suffield wrote:
> > > void shoe()
> > > {
> > >   /* Do some complicated stuff */
> > >   if (foo == NULL)
> > > 	goto cleanup;
> > >   /* Continue complicated stuff */
> > >   if (bar == 3)
> > > 	goto cleanup;
> > >
> > > cleanup:
> > >   /* Cleanup */
> > > }
> >
> > Good grief, that's *terrible* C. Don't do things like that. The
> > problem here is not a lack of exceptions, it's just bad code. As
> > usual.
> As usual? OK.
> That is an often used convention, used by many substantial pieces of C code 
> that you are running on your system right now. Admittedly it is much more 
> often used in system level situations than application code. 

In fact, K&R even recommends this approach when cleanup is required, so
it's not as if there isn't precedent:
   This organization is handy if the error-handling code is non-trivial,
   and if errors can occur in several places. [1]

I've seen this approach used to great advantage in several fairly large
(500,000+ line) pieces of Oracle-based software.  We standardized on a
common structure for each function (at least, each function of a certain
complexity), including a return status variable and an EXIT_FUNC tag
that was always immediately after all normal program functionality and
immediately before all cleanup.  Whenever we ran into a "fatal" error,
we logged a message, set the return status appropriately and then jumped

This gave us an obvious place to free memory, clean up database
connections, roll back or commit transactions, etc., etc.  It was good
that all cleanup was done exactly the same way (no duplication, no
omissions).  It was also good that all of the functions had a similar
structure, which helped minimize the learning curve for a code-base this

Yes, you can argue that if error-handling gets really complicated, you
might be better off moving some of that code to smaller functions which
each have their own, less-complicated error-handling.  However,
sometimes you still need one good place to do consistent cleanup, and
this approach seems to work as well as any I've seen.


[1] Section 3.8 "Goto and Labels", page 65 in my 1988 edition.

Kenneth J. Pronovici <pronovic@debian.org>

Attachment: pgpc25V_kk_XH.pgp
Description: PGP signature

Reply to: