An amusing piece of code
kenny at uiucdcsb.CS.UIUC.EDU
kenny at uiucdcsb.CS.UIUC.EDU
Thu Apr 17 04:02:00 AEST 1986
/* Written 4:26 pm Apr 12, 1986 by stevesu at copper.UUCP in uiucdcsb:net.lang.c */
Most people agree that goto's are pretty acceptable for handling
error conditions. For instance:
if(stbuf.st_uid != getuid())
{
nope: printf("I don't think you want to delete this file.\n");
return;
}
if(strcmp(name, "vmunix") == 0)
goto nope;
unlink(name);
return;
Steve Summit
tektronix!copper!stevesu
/* End of text from uiucdcsb:net.lang.c */
You've chosen a pretty bad example. It's more sensible to code what you're
writing as:
if (stbuf.st_uid != getuid ()
|| strcmp (name, "vmunix") == 0) {
printf ("I don't think you want to delete this file.\n");
}
else {
unlink (name);
}
The real use of goto's as error exits is as a panic exit from a set of
deeply nested control structures; this is generally a goto *out* of a block
and not *into* one:
while (something)
while (something else)
if (something terrible happens) goto quit;
....
return;
quit:
(handle the error here)
with as many goto's as are necessary to handle all the error conditions.
In many cases this panic exit actually has to cross function boundaries;
a reason that I insist (over some of my more academically minded colleagues'
loud objections) that setjmp/longjmp pairs are a necessary evil.
In short, the use of goto as an error exit is a red herring when discussing
whether goto into blocks is permissible. My $.02 says that it isn't necessary,
ever, and it really messes up any serious attempt to optimize, so why not trash
it?
Kevin Kenny
University of Illinois at Urbana-Champaign
UUCP: {ihnp4,pur-ee,convex}!uiucdcs!kenny
CSNET: kenny at UIUC.CSNET
ARPA: kenny at B.CS.UIUC.EDU (kenny at UIUC.ARPA)
"Yes, understanding today's complex world is a bit like having bees live in
your head, but there they are."
More information about the Comp.lang.c
mailing list