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: 103376,751584f55705ddb7
X-Google-Attributes: gid103376,public
From: Alan Brain <aebrain@dynamite.com.au>
Subject: Re: Side-effect arithmetic again [was: Ada ... in embedded systems]
Date: 1996/03/22
Message-ID: <4ivb6t$q41@fred.netinfo.com.au>#1/1
X-Deja-AN: 143800881
references: <4hv2fb$6ra@cville-srv.wam.umd.edu>
 <4il3ce$fqa@saba.info.ucla.edu> <4in8ko$klb@watnews1.watson.ibm.com>
 <EACHUS.96Mar19195517@spectre.mitre.org> <4iq2ia$lk7@dayuc.dayton.saic.com>
content-type: text/plain; charset=us-ascii
organization: Netinfo Pty Ltd - Canberra Australia
mime-version: 1.0
newsgroups: comp.lang.ada
x-mailer: Mozilla 1.2N (Windows; I; 16bit)
Date: 1996-03-22T00:00:00+00:00
List-Id: <comp.lang.ada>

John G. Volan <John_Volan@ccmail.dayton.saic.com> wrote:
------------------------------------------------------------------------
>	generic
>	    type Item is (<>);

------------------->8-----------------------------

May I humbly suggest adding a few exceptions to the spec? There are 
quite a few places where CONSTRAINT_ERROR is possible at run-time, and 
it's usually a pretty good idea to map this into something a bit more 
informative, so the caller can know where the error occurred.

I know it's obvious, but some readers won't be familiar with Ada93, so 
please bear with me if I give an example:

     Supposing you have a type

subtype INTEGER_DEGREES_TYPE is INTEGER range 1..360;

VFR_BEARING : INTEGER_DEGREES_TYPE := 360;


     Then 

INCREMENT(VFR_BEARING);

     would raise a CONSTRAINT_ERROR, always.

In order to make a really reliable, fault-tolerant ( and bug-tolerant ) 
program, it would be really great if instaed of the generalised 
CONSTRAINT_ERROR being handled, a 
DISCRETE_ARITHMETIC_FOR_INTEGER_DEGREES.INCREMENT_OVERFLOW_ERROR was 
raised, differentiated from anything else in the same block that could 
cause CONSTRAINT_ERROR.

So code could be (withs, uses omitted for clarity)


DETERMINE_VFR_BLOCK:

begin
  -- do something here --
  INCREMENT(VFR_BEARING);
  -- do something else here --

exception
  when INCREMENT_OVERFLOW_ERROR => do some sort of recovery;
  when CONSTRAINT_ERROR         => do something else;
  when others                   => do something else again;

end DETERMINE_VFR_BLOCK;

Just my 2c.