C style

[preece at ccvaxa.UUCP]

> /* Written  7:44 pm  Oct 28, 1985 by mikes at 3comvax.UUCP in
> ccvaxa:net.lang.c */
> Scott's example done the RIGHT (i.e. my :-))  way:
> 	for(i = 0; i < 100; i++) {
> 		if(f1(x) == OK &&
> 		   f2(x) == OK &&
> ...
----------
Sigh.  or "Posting Examples Considered Harmful."  The example wasn't
meant to be complete or realistic, it was intended to be a skeletal
example of the KIND of coding that happens using nesting as opposed
to the KIND of coding that happens using break.  The short-circuited
evaluation of the big if works fine if you don't do anything in between
the tests, as my skeletal example didn't.  But if there is some
tissue between the bones you either have to write horrible expressions
that are MUCH harder to read or you have to write the logical structure
as separate tests so that you can have blocks of code between the
tests.
----------
> I didn't do anything with checkreturn, because Scott's code didn't use
> it for anything, either.
----------
You, like some other respondents, failed to notice that my loop
terminates on error; yours just assigns zero to cells on which
the error condition was noticed.  Checkreturn was used (in the nested
example) for that purpose.
----------
> In the more usual case where you need to take different error actions
> depending on several successive function calls, I venture to state that
> It Should Be Done This Way: ...
----------
Your framework is perfectly appropriate for the kind of situation it
addresses, which is different from the kind of situation I was
describing.

I liked your pointing out that the error clauses had to back out any
side effects of all previously applied functions, which is an important
reminder.  On the other hand, the blanket statement that side effects
are bad practice is a little hard to support.  Define "side effects."
Do you mean that no function call should alter the global state of
the computation except by the value(s) it returns?  That's a pretty
tall order.  Many function calls are done specifically for their
side effects (I/O, for instance).  In an error checking sequence
you would like to appear (to higher levels of the program) to be
performing an atomic action, but I think it's unrealistic to demand
more than that there be some way of resetting the state when an
error is detected.

-- 
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece