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: "Mark L. Fussell" Subject: Re: Building blocks (Was: Design By Contract) Date: 1997/09/23 Message-ID: <3427B839.6FB5@chimu.com>#1/1 X-Deja-AN: 274819465 References: <5v34m5$pl9$1@trumpet.uni-mannheim.de> <34215E3D.77AE@gsfc.nasa.gov> <3421E190.49CC@chimu.com> To: Jon S Anthony X-Trace: 875018271 13971 (none) 206.86.0.12 Organization: ChiMu Corporation Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-09-23T00:00:00+00:00 List-Id: Jon S Anthony wrote: ... > Is the Eiffel approach really conceptually different from a recursive > "retry" (where the Eiffel retry is basically a structured goto the > beginning of the current invocation)? For example, > > procedure P (.... Attempts : Natural := 0) is > ... > if Attempts = 0 then > -- do main stuff > else > -- do nothing > end; > exception > when others => -- (or more specific exception...) > P(....Attempts+1) > ... > end P; I agree that this is pretty similar to my/OOSC-2s example. The obvious difference is you have publicly exposed the 'attempts' variable which is an implementation detail, but of course this could be hidden through a second, private procedure/feature that is delegated to. And the general case could have 0..N state variables passed back in. The more important [IMO] difference is the 'feel' again. The above code shows the flexibility in exception handling that Eiffel consciously chose to disallow: having anything other than the current invocation's main body 'continue' from an exception. So the above code functions almost identically to the Eiffel code but it implies the possibility of a different solution (different responsibility) which Eiffel never would. Whether you view this as a guiding hand or hand-cuffs is probably very subjective. I doubt there is any empirical evidence that this particular Eiffel restriction produces better software[1], but it obviously does fit in well with Eiffel as a whole as it came from the same mind. --Mark mark.fussell@chimu.com [1] In my previous post I guessed at what it might help with: returning you to thinking about how to satisfy the routine call after you recover from the exception itself. You certainly have to jump through an extra hoop to carelessly ignore an exception: you don't have the Java/C++/standard short-circuit construct: try { ... } catch (Exception e) {}; But as multiple people have noted, there is a time for everything, and the above construct can be useful, for example, if you have a valid state before the 'try' and nothing within the 'try' will invalidate it (i.e. it will only move to another valid state or not at all). So we always return to the same meta-question: when should programmers be free but disciplined and when should they be confined? What tradeoffs are appropriate in each context? Hmmm... should be a 'Pattern' for this somewhere out there. i ChiMu Corporation Architectures for Information h M info@chimu.com Object-Oriented Information Systems C u www.chimu.com Architecture, Frameworks, and Mentoring