From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,f66d11aeda114c52 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,f66d11aeda114c52 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Building blocks (Was: Design By Contract) Date: 1997/09/19 Message-ID: X-Deja-AN: 273926533 References: <5v34m5$pl9$1@trumpet.uni-mannheim.de> <34215E3D.77AE@gsfc.nasa.gov> <3421E190.49CC@chimu.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-09-19T00:00:00+00:00 List-Id: In article <3421E190.49CC@chimu.com>, Mark L. Fussell wrote: >A close equivalent in Eiffel is the following example. This is actually >a variation from the discussion in Section 12.5 of OOSC-2. I read about this in OOSC-1, and I didn't buy it. It seems to me that retry has nothing at all to do with whether an operation can "pretend it succeeded". The thing that prevents that pretense is having a spec for what the routine in supposed to do. In Eiffel, this is represented by the postcondition and invariant (which may include executable boolean expressions, plus comments). In Ada, it's represented mainly by comments, but perhaps also by constraints, and maybe even raise_statements in the code. If Eiffel had Ada-style exception handlers, I don't see how this would do any damage. The exception handler would still be required to obey the postcondition. Either way, there's always the danger that the programmer forgot to handle some case correctly. But that's true even without exceptions: if then else end if; If is usually True, and your test cases fail to exercise the else branch, then you have a bug that a customer might trip over. Likewise, if the main body of a procedure is right, but the exception handler is wrong, you have a bug. Either way, the post condition will catch it at run time. I don't see how "retry" enhances the ability of postconditions to find bugs. Furthermore, retry seems to have all the bad properties of goto. And the worst sort of goto -- the kind that jumps backwards in the code, forming a loop, without actually writing "loop" at the front. >is > -- The Eiffel version of the above >local > attempts : INTEGER -- FYI: initializes attempts to 0 >do > if attempts = 0 then > -- do main stuff > else > -- do nothing > end >rescue > attempts := attempts + 1 > retry >end The above code seems obfucatory to me. If you really want to retry, I would much rather have an explicit loop: loop begin ... -- do main stuff exit; exception when Some_Error => null; end; end loop; Often, you want to do something *different* when the exception occurs (still, of course, obeying the postcondition). That's what the above Eiffel code does, but in a confusing way. There's no warning at the top of the code that we might be entering it from the exception handler. In that regard, retry is *worse* than a goto -- at least with a backward goto there's a label there warning you that some other thing might jump here. It seems much clearer to say "do THIS in the normal case, but if you get an exception, do THAT instead". And of course, THIS and THAT must obey postconditions. >"This mechanism strictly adheres to the Disciplined Exception Handling >principle: either a routine succeeds, that is to say its body executes >to the end and satisfies the postcondition, or it fails. This is a bogus definition of "succeed". The only sensible definition is "obeys the postcondition". And that could be achieved just as well without retry. >... When >interrupted by an exception, you may either report failure or try your >normal body again; in no way can you exit through the rescue clause and >pretend to your caller that you succeeded." But if exception handling were more Ada-like, it would *still* be the case that "in no way can you ... pretend ...". You would still be required to obey the postcondition. >Most of the difference between the Eiffel and Ada approach is really >"what it feels like" in the exception handler. Eiffel's exception >handler give you a chance to retry the main body which can than do what >ever it wants (within its contract), but in so doing returns you to >thinking about how to satisfy the routine call. The Ada (and many other >languages) approach allows you to try to both recover from the exception >and satisfy the routine call in one place. This may lead you to forget >to do one or both of these responsibilities. Just the opposite, IMHO. With retry, you might forget, when writing the main body, that you might get there via retry. With the Ada approach, you know which situation you're in, and you can write code that satisfies the postcondition on that basis -- no need for bogus state variables like the above "attempts", which seem to obfuscate. >Certainly Eiffel calls out the 'do nothing' behavior more strongly by >having it be in the main body: > if attempts = 0 then > -- do main stuff > else > -- do nothing > end >This looks much stranger and more suspicious than the equivalent: > begin > ... some code > exception > when others => > null; I disagree. Unless the "when others => null;" is inside a loop (which I prefer to indicate by saying "loop", rather than the goto-ish backwards jump of "retry"), it looks mightily suspicious to me. On the other hand, in the Eiffel case, if the main body simply said "do main stuff" (without the if statement), then it seems easier to forget that we might get here with attempts > 0. >In the quotes above, the following remark implies more than it means: >"in no way can you exit through the rescue clause and pretend to your >caller that you succeeded". Since the caller only sees the routine >return, it would not know whether you 'pretended to succeed' via the >rescue/exception clause or through the main body of the routine. >Pretending to succeed is possible one way or the other. Exactly. >...In either case, >your exiting normally implies you fulfilled your contract >(post-condition) and if Ada had post-conditions then: > when others => null; >should have to satisfy them or throw a new exception. To be fair, the >sentence before BM defined 'succeed' more restrictively as the execution >of the body, but that definition is Eiffel specific and the word >'success' has a more general connotation. Agreed. In summary, I think it's postconditions that help make routines work properly in all cases (including exceptional cases). I don't see any way in which "retry" helps ensure that postconditions are obeyed, and I think retry simply makes the code more confusing. - Bob