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-Thread: 103376,b3f788f59498d3af
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!news.germany.com!news.belwue.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 20 Jun 2007 08:21:16 +0200
From: Georg Bauhaus <bauhaus.rm.tsoh@maps.futureapps.de>
Organization: #
User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Exceptions and out procedure arguments (using GNAT GPL)
References: <79c673pq5htg508nkoi935n3udqg5ps7r8@4ax.com>
 <1182181497.595409.300500@a26g2000pre.googlegroups.com>
 <drle731ukcmhlt5km966imoudr5s92napd@4ax.com>
 <1182238493.512406.168820@o61g2000hsh.googlegroups.com>
 <1182266486.650797.262430@a26g2000pre.googlegroups.com>
 <u1ofbjnyd74k$.9604oalmbm4q$.dlg@40tude.net>
In-Reply-To: <u1ofbjnyd74k$.9604oalmbm4q$.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <4678c6a0$0$23135$9b4e6d93@newsspool1.arcor-online.net>
NNTP-Posting-Date: 20 Jun 2007 08:18:08 CEST
NNTP-Posting-Host: e34ba72d.newsspool1.arcor-online.net
X-Trace: 
 DXC=\h[1dIfWW7?i6K;>iZ]763ic==]BZ:af>4Fo<]lROoR1Fl8W>\BH3Y2Z7ndf4S17[5A:ho7QcPOV3B;>\h05OfF0D\OCbRZ>IT;
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:16252
Date: 2007-06-20T08:18:08+02:00
List-Id: <comp.lang.ada>

Dmitry A. Kazakov wrote:
> On Tue, 19 Jun 2007 08:21:26 -0700, Adam Beneschan wrote:
> 
>> My gut feeling is that, in
>> the abstract, a subprogram should either produce a result *or*
>> (perhaps) raise an exception, but not both; in general, if your
>> definition of a subprogram is that, under certain conditions, the
>> subprogram will raise an exception AND the caller can expect a certain
>> value to be returned (whether in an OUT parameter or an IN OUT or a
>> global or in something pointed to by an access parameter or whatever)
>> even though an exception is raised, the design is wrong.  It's better
>> to use an OUT status code of some sort in that case.
> 
> I don't think this is a good advice. In my view a right design assumes that
> whether an exception is propagated or not, the subprogram should not leave
> anything in an undefined state.

Including unititialised in-variables? Partially initialised records?

And can you document all side effects on by reference (or global)
variables at all, in the presence of exceptions? In the general case?
(Considering this is Ada, which has exceptions, not SPARK, which is
about exceptional things not happening :-)