Re: Building blocks (Was: Design By Contract)

[Alan E & Carmel J Brain <aebrain@dynamite.com.au>]

Anonymous wrote:

> > If you want to resume, or retry, or whatever, you need to confine the
> > exception to it's own block. A typical example looks something like:
> >
> > (Declarations, Constants omitted for simplicity)
> >
> > UnTransmitted := true;
> > ReTryCounter := 0;
> >
> > while UnTransmitted loop
> >
> >   if ReTryCounter > MaxRetries then
> >      raise LineContinuouslyBusy; end if; -- Line Too busy
> >                                          -- Report this upwards
> >   Transmission_Attempt_Block :
> >   begin
> >
> >     Ethernet.TryToTransmit;
> >     UnTransmitted := false; -- Successful Transmission
> >
> >   exception
> >     when Ethernet.LINE_BUSY =>
> >       ReTryCounter := ReTryCounter+1; -- Try again
> >                                         -- Note that this 'handles'
> >                                         -- the exception
> >     when Ethernet.NACK =>
> >         Untransmitted := false;         -- Ignore Negative Ack.
> >                                         -- Again, exception handled.
> >     when others => raise;
> >       -- something unexpected and Nasty, Propagate it out!
> >
> >   end Transmission_Attempt_Block;
> >
> > end loop;
> >
> 
> This doesn't seem typical to me. It differs from typical in
> 
> 1. Using mixed-case identifiers instead of underline-separated
> identifiers (ReTryCounter instead of Re_Try_Counter).

Good point, thanks for the correction. Ain't walk-through's wonderful?
 
> 2. Using while instead of loop/exit (ref. Ichbiah, Barnes, & Firth, "Ada
> Launch," 1980 Dec 10, videotape, on why while was included in the
> language).

I'd defend this one on style grounds, and believe the matter is
religious. I have no access to this video. Any other sources? BTW
perfectly willing to believe I'm wrong, I just want to know why...

> 3. The design of Ethernet is faulty, since it uses exceptions for
> non-exceptional circumstances (line busy, NACK received).

Depends on the domain. Either of these may be exceptional (e.g. in a
1-way broadcast architecture) or normal (e.g. many nodes, all of whom
may talk).
 
> 4. Unusual formatting of the if.

Style again. If expressible more clearly on one or two lines, use that,
otherwise a more normal format would be

  if CONDITIONAL then
    STATEMENT;
    STATEMENT;
  end if;

or even

  if CONDITIONAL
  then
    STATEMENT;
  end if;
 
> If we have to use Ethernet as is, I'd say the following is more typical
> 
> Retry_Counter := 0;
> 
> Send : loop
>    if Retry_Counter > Max_Retries then
>       raise Line_Continuously_Busy;
>    end if; -- Line too busy; report this upwards
> 
>    Try_One : begin
>       Ethernet.Try_To_Transmit;
> 
>       exit Send; -- Successful transmission

I'd insert a blank line here for readability
and a few others, as below:

>    exception -- Try_One

>    when Ethernet.Line_Busy =>
>       Retry_Counter := Retry_Counter + 1; -- Try again

>    when Ethernet.Nack =>
>       exit Send; -- Accept NACK as success

>    end Try_One;

> end loop Send;


Makes sense to me. OTOH there is a school of thought that eschews
multiple exits. But that's another story. The point is, is that both
versions show in a minimum number of lines the various options one has
in Ada ( -83 at least, there are more in -95), which was the basic idea.

> "You brightly-colored, mealy-templed, cranberry-smelling, electric
> donkey-bottom biters."

Was this meant personally? (<g> added for the hard-of-thinking) If so, I
take exception! (That's supposed to be a pun.... never mind...)
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale