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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no 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: Joachim Durchholz Subject: Re: Building blocks (Was: Design By Contract) Date: 1997/09/20 Message-ID: <3423BE13.9C3852A4@munich.netsurf.de>#1/1 X-Deja-AN: 274573446 References: <5v34m5$pl9$1@trumpet.uni-mannheim.de> <34215E3D.77AE@gsfc.nasa.gov> <3421E190.49CC@chimu.com> X-Priority: 3 (Normal) Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-09-20T00:00:00+00:00 List-Id: Robert A Duff wrote: > The exception handler would still be required to obey > the postcondition. With the exception that postconditions (even if you writen them down as raise_statements) aren't handled as well as in Eiffel: They aren't automatically included in the package documentation, and they aren't automatically inherited by descendants (if it's a tagged type). > Either way, there's always the danger that the > programmer forgot to handle some case correctly. Agreed. > 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. I don't particularly like the semantics of retry. I've already seen Eiffel code that was so obfuscated by squeezing the error handling logic into a loop that it was actually wrong. And the author was actually one of the Big Names in the Eiffel community... Personally, I'd prefer the C++/Java style: try -- code that may raise an exception on do -- exception handler on do ... end (ad-hoc syntax). I don't like the Ada solution either. It is "structured" in that it will resume execution at the point where the execution occurred, but that's *very* wrong. The exception handler can't know at which point in the code the exception occurred (maybe even in a subroutine!), so it can't know what to do to fix the problem. The Eiffel solution is marginally better - it says "if it don't work, don't try to fix it, try again if there is anything to do about it". This policy isn't wrong, but it doesn't cover all cases where an exception might be raised. [good examples of obfuscated retry statements snipped] > >"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. Yup. Though Ada has no formal connection to postconditions, so it doesn't offer us guidelines what to do about an exception. What's disciplined about Eiffel exceptions is not the retry instruction, which is somewhat secondary. The discipline of exception handling in Eiffel has other sources: - A precise definition of what an exception indicates (namely a routine that fails to fulfill its postcondition - other languages, lacking the notion of postcondition, can't even start to compete) - A strict guideline when to raise an exception explicitly: if something uncontrollable happens that makes fulfilling a postcondition imnpossible. Such uncontrollable events are: actions by concurrent threads, bugs, unhandled exceptions in called routines, and algorithms where controlling the problems is nearly as expensive as just trying (like in matrix inversion, where determining wether a matrix is invertible takes nearly as long as just starting the inversion and aborting if a division by zero occurs). - A strong guideline *not* to use exceptions as interprocedural goto. (I'm pretty sure that this is frowned upon by all serious Ada shops, but it's still a difference if such a guideline is expressed in all textbooks from the beginning of if you have to install such a policy. I call such conventions "language culture" - it's not part of the formal specification, but important enough to strongly influence the average quality of programs written in a language.) > 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. Right. Regards, Joachim -- Please don't send unsolicited ads.