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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a00006d3c4735d70
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2004-03-02 14:43:55 PST
Path: 
 archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!newsfeed1.easynews.com!easynews.com!easynews!elnk-pas-nf1!newsfeed.earthlink.net!sn-xit-02!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: In-Out Parameters for functions
Date: Tue, 2 Mar 2004 16:43:21 -0600
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <104a3hbc01jpjde@corp.supernews.com>
References: <4020C947.81A6D703@0.0>   <1075987360.225622@master.nyc.kbcfp.com>
 <40236C0B.E988E003@0.0> <pan.2004.02.24.01.44.30.311621@email.ro>
 <1077634311.254581@master.nyc.kbcfp.com>
 <pan.2004.02.24.23.23.33.578111@email.ro>
 <mailman.20.1077669870.327.comp.lang.ada@ada-france.org>
 <pan.2004.02.25.09.01.17.858502@email.ro>
 <1077718871.47635@master.nyc.kbcfp.com>
 <54cp3095jmv8s17h63d4bjdus0tec7l7pt@jellix.jlfencey.com>
 <1077721343.481619@master.nyc.kbcfp.com> <LIidnT3Ca4JDVaHdRVn-jw@comcast.com>
 <1077727853.904323@master.nyc.kbcfp.com> <B8WdnRy5IL0WaqDdRVn-jA@comcast.com>
 <1077810250.28474@master.nyc.kbcfp.com> <YLSdnQ0lYfaSTN3dRVn-iQ@comcast.com>
 <zld0c.8152$qX5.3749@nwrdny03.gnilink.net>
 <vLCdnZQsroNOb9zd4p2dnA@comcast.com> <1078162736.111267@master.nyc.kbcfp.com>
 <fYudnfHKwtGXZ97d4p2dnA@comcast.com>
 <8qW0c.24142$TF2.22229@nwrdny02.gnilink.net> <plbrnf4oss.fsf@sparre.crs4.it>
 <1078241064.575279@master.nyc.kbcfp.com> <plfzcr2r3m.fsf@sparre.crs4.it>
 <1078245216.689285@master.nyc.kbcfp.com>
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Complaints-To: abuse@supernews.com
Xref: archiver1.google.com comp.lang.ada:6020
Date: 2004-03-02T16:43:21-06:00
List-Id: <comp.lang.ada>

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1078245216.689285@master.nyc.kbcfp.com...
> Jacob Sparre Andersen wrote:
> > But if this really is a serious problem for you, you can handle it by
> > putting each of the five assignments in your sequence of statements
> > within its own begin-exception-end block.
>
> That's not really the point. If I know in micro-detail where a check
> is failing, I could just as easily make it not fail.

Not really. Try writing a multiply routine that detects overflow without
handling the exception.

>  What I expected
> (which will probably earn me another blast from RE for not getting
> the Ada mindset) was that the reason for l-d checks is to prevent the
> kind of errors you find in C, namely undetected erroneous changes that
> trigger problems at some remove from the place where they occurred.
> It seems to me that the Ada rules allow the same sort of thing to
> happen - if I have a handler at a high level for a language-defined
> error, it's possible that any number of objects may have been left in
> an abnormal state when the exception triggered, and I will encounter
> erroneous (and possibly undetected) behavior at some later point.

Handling l-d checks requires great care. It's generally only safe to do so
in a very narrow section of code (like the overflow check mentioned above),
or in a very broad chunk of code (the whole subsystem). Usually, you just
want to log them and either exit or reinitialize everything and start over.
Ada doesn't really support continuation from constraint_error or
storage_error.

                 Randy.