Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site ccvaxa Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!preece From: preece@ccvaxa.UUCP Newsgroups: net.lang.c Subject: Re: C style Message-ID: <2600025@ccvaxa> Date: Wed, 30-Oct-85 11:11:00 EST Article-I.D.: ccvaxa.2600025 Posted: Wed Oct 30 11:11:00 1985 Date-Received: Sat, 2-Nov-85 04:21:53 EST References: <1556@brl-tgr> Lines: 53 Nf-ID: #R:brl-tgr:-155600:ccvaxa:2600025:000:2374 Nf-From: ccvaxa.UUCP!preece Oct 30 10:11:00 1985 > /* Written 7:44 pm Oct 28, 1985 by mikes@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