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.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no 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.teledata-fn.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Exceptions and out procedure arguments (using GNAT GPL)
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
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>
 <4678c6a0$0$23135$9b4e6d93@newsspool1.arcor-online.net>
Date: Wed, 20 Jun 2007 10:02:31 +0200
Message-ID: <1o6rnwgzezcr2$.mv31ct5mmmso$.dlg@40tude.net>
NNTP-Posting-Date: 20 Jun 2007 09:59:42 CEST
NNTP-Posting-Host: 822a38cc.newsspool1.arcor-online.net
X-Trace: 
 DXC=GC>5HR^2lhUYQ5E:l<XC@Sic==]BZ:af^4Fo<]lROoRQFl8W>\BH3YR5>=EAGYI@jQDNcfSJ;bb[UFCTGGVUmh?TLK[5LiR>kgR@`JWFTfHUe\
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:16257
Date: 2007-06-20T09:59:42+02:00
List-Id: <comp.lang.ada>

On Wed, 20 Jun 2007 08:21:16 +0200, Georg Bauhaus wrote:

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

OK, clearly this applies only to the things the subprogram is responsible
for.

> And can you document all side effects on by reference (or global)
> variables at all, in the presence of exceptions?

That depends on the meaning of "all." Certainly, we cannot control
side-effects on the CPU's cache or on the green gas emission caused by
consuming electricity during subprogram execution...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de