Re: Building blocks (Was: Design By Contract)

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

Joachim Durchholz wrote:

> Personally, I'd prefer the C++/Java style:
>   try
>     -- code that may raise an exception
>   on <exception identification> do
>     -- exception handler
>   on <other exception id> 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.

Eh???

The syntax for Ada looks like:

procedure WhatEver is

begin
  -- statements
  -- more statements
  -- end of normal execution
exception
  when SOME_ERROR => do something;
  when SOME_OTHER_ERROR => do something else;
  when others => raise; -- just propogate to caller
end WhatEver;

There is no resumption! Any exception raised between the "begin" and
"exception" immediately causes abandonment of normal execution, like a
GOTO, to the exception block.

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;

Note that the LINE_BUSY exception, declared in package ETHERNET is
normal, expected, and handlable locally, at least up to a point. Any
other exceptions coming from a call to Ethernet.TryToTransmit will be
propagated upwards and outwards: there is not enough data locally to
determine what to do here. Similarly, if the line is continuously busy,
an exception stating this is propagated upwards. In the case of a NACK
exception, cross fingers, hope it's OK, etc. Normally a VERY bad idea,
but on hardware which gives 30% or more false positives, it may be the
only way to go.

Personally, I like the flexibility.
 
-- 
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