Error Handling
Otto J. Makela
otto at tukki.jyu.fi
Fri Sep 28 17:09:52 AEST 1990
In article <837 at babcock.cerc.wvu.wvnet.edu> vrm at cathedral.cerc.wvu.wvnet.edu (Vasile R. Montan) writes:
[What is the best way for a function to test for errors ?]
Method 1: Return Error Code When Error Is Encountered
The problems I have with this are first it goes against
software engineering principles which say that all functions
should have one entry point and one exit point. Secondly
some functions do have some standard clean up to do.
[...]
Method 2: Set Error Code and Return Only at End
The problem I have with this is that I don't want to do
later work if a previous error occured. I just want to
clean up and return. This forces me to continuously check
if a previous error occured.
[...]
Method 3: Use GOTO to Create Exception Handler
Of course this breaks the golden rule of software
engineering of "absolutely positively no GOTO's in your
program."
I would go for method 3 everytime (if the clean-up is trivial, go for 1).
Remember, rules like "no GOTOs" are inventions of Pascal weenies, and I
wouldn't call them golden :-)
Simplistic rules like this are supposedly a alternative to using common
sense in programming (no smiley here). They are human inventions, they
didn't come down from the mountain engarved in stone tablets.
Seriously, do you think method 2 is more "structured" than method 3 only
because it has no gotos in it ? I have seen awful constructs which are
supposedly structured programming, in which you have a dozen of "break-
out-flags" from nested loops because you can't use gotos or breaks (the
latter being only gotos to the exit point of the loop).
(I have a weird feeling I'm going to be flamed by religiously structured
zealots... what are you doing with that napalm ?)
--
/* * * Otto J. Makela <otto at jyu.fi> * * * * * * * * * * * * * * * * * * */
/* Phone: +358 41 613 847, BBS: +358 41 211 562 (CCITT, Bell 24/12/300) */
/* Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPE */
/* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * * * * * */
More information about the Comp.lang.c
mailing list