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,FREEMAIL_FROM
	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 08:33:38 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!newshosting.com!nx01.iad01.newshosting.com!news-out.visi.com!petbe.visi.com!news.octanews.net!ash.uu.net!spool.news.uu.net!not-for-mail
Date: Tue, 02 Mar 2004 11:33:26 -0500
From: Hyman Rosen <hyrosen@mail.com>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: In-Out Parameters for functions
References: <4020C947.81A6D703@0.0> <402232E9.3EE15B4B@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>
In-Reply-To: <plfzcr2r3m.fsf@sparre.crs4.it>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Organization: KBC Financial Products
Message-ID: <1078245216.689285@master.nyc.kbcfp.com>
Cache-Post-Path: master.nyc.kbcfp.com!unknown@nightcrawler.nyc.kbcfp.com
X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/)
NNTP-Posting-Host: 204.253.250.10
X-Trace: 1078245216  17310 204.253.250.10
Xref: archiver1.google.com comp.lang.ada:6008
Date: 2004-03-02T11:33:26-05:00
List-Id: <comp.lang.ada>

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. 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.