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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC 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: Alan E & Carmel J Brain <aebrain@dynamite.com.au>
Subject: Re: Building blocks (Was: Design By Contract)
Date: 1997/09/24
Message-ID: <342A0AC6.2F2F@dynamite.com.au>#1/1
X-Deja-AN: 275154761
References: <5v34m5$pl9$1@trumpet.uni-mannheim.de>
 <wihnDCAGPDI0IwlD@treetop.demon.co.uk> <34215E3D.77AE@gsfc.nasa.gov>
 <3421E190.49CC@chimu.com> <EGrz21.GoG@world.std.com>
 <3423BE13.9C3852A4@munich.netsurf.de>
Reply-To: aebrain@dynamite.com.au
Organization: @home
Newsgroups: comp.lang.ada,comp.lang.eiffel
Date: 1997-09-24T00:00:00+00:00
List-Id: <comp.lang.ada>


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