Re: Building blocks (Was: Design By Contract)

["Mark L. Fussell" <mark.fussell@chimu.com>]

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