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: paul.johnson@gecm.com (Paul Johnson) Subject: Re: Building blocks (Was: Design By Contract) Date: 1997/09/10 Message-ID: <5v5l26$h62$3@miranda.gmrc.gecm.com>#1/1 X-Deja-AN: 271225412 References: <5ulurp$aj8$1@miranda.gmrc.gecm.com> <5un58u$9ih$1@gonzo.sun3.iaf.nl> <5v0bph$n98$2@miranda.gmrc.gecm.com> Organization: GEC-Marconi Research Centre Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-09-10T00:00:00+00:00 List-Id: In article , mheaney@ni.net says... >In article , >Brian Rogoff wrote: >>>In fact the Eiffel exception mechanism is superior to the Ada one >>> because it is built on a theoretical model of software engineering. Brian Rogoff didn't write that, I did. >Can any of the Eiffel guys explain this a bit more? I'm curious what is >meant by a "theoretical model of software engineering." Can someone post >some references to the theory behind the Eiffel exception mechanism? I was referring to "design by contract", which underpins pretty much the whole of Eiffel. See OOSC-2 for the fullest explanation yet. E:TL also has quite a lot of stuff about it, and the theory was laid out in OOSC-1 in enough detail for a first pass. I think that there is also an outline on the ISE web site (www.eiffel.com). >I've always been curious about the semantics of exception propagation, >because it doesn't correspond to anything in pure math (or does it?). Under DbC, the server class offers a "contract" specified by the preconditions, postconditions and invariants. When a routine is called, the client must fulfil the preconditions (otherwise there is a bug in the client). Once these preconditions are fulfilled the server class must either fulfil the postconditions and invariants *or* raise an exception. In everyday programming this just means that it must fulfil its postconditions and invariants, but for instance an RPC mechanism might trigger an exception if it discovers that the network is down. Once an exception has been triggered the class has two options: 1. Tidy up any internal state and pass the exception back to the caller. 2. Try again, possibly using a different stratagy. Note that there is no third option. Also note that the following are forbidden: * Silent failure. If the server cannot fulfil its contract then it *must* raise an exception. * Exceptions as normal control structure. An exception indicates that something has gone wrong: things are not working as intended. It might be that the "something" is outside the software's control (e.g. network down) and the software has been written to handle this gracefully, but there is still something wrong. A dictionary lookup routine does not return an exception if it fails to find an entry. >It would be cool if you could check at compile time that all exceptions >were being handled by the client, and that only the exceptions advertised >by a supplier get raised (and only in the specified state). Maybe that's >the Eiffel model already. In Eiffel there is not much distinction between exceptions. You can examine an exception, but thats more so you can put something useful in the error log than for any control-flow reasons. As far as control flow is concerned, the key fact is that the routine has failed. Nothing else matters. In Ada exceptions seem to be treated as a sort of out-of-band enumerated type. Paul. -- Paul Johnson | GEC-Marconi Ltd is not responsible for my opinions. | +44 1245 242244 +-----------+-----------------------------------------+ Work: | You are lost in a twisty maze of little Home: | standards, all different.