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,c80e6f742e73478f
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sat, 13 Mar 2010 19:33:55 +0000
From: Georg Bauhaus <see.reply.to@maps.futureapps.de>
Reply-To: rm.tsoh-bauhaus@maps.futureapps.de
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Ensuring postconditions in the face of exceptions
References: 
 <820d96c0-5d67-4b8c-8c5b-811ca4f1127e@g26g2000yqn.googlegroups.com>
 <ruqub2y84rqj.179q01lxzgatj$.dlg@40tude.net>
In-Reply-To: <ruqub2y84rqj.179q01lxzgatj$.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <4b9bda93$0$6575$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 13 Mar 2010 19:33:55 CET
NNTP-Posting-Host: 8c106c69.newsspool3.arcor-online.net
X-Trace: 
 DXC=USYhfmlgOIiFXUDVUnEXQmMcF=Q^Z^V3h4Fo<]lROoRa8kF<OcfhCOkEUk<]:HK63aPCY\c7>ejVhbHfn09Ybnah`XNf[G0e<9f
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:10530
Date: 2010-03-13T19:33:55+01:00
List-Id: <comp.lang.ada>

Dmitry A. Kazakov wrote:
> On Fri, 12 Mar 2010 01:13:45 -0800 (PST), Ludovic Brenta wrote:
> 
>> Consider the procedure:
>>
>> type T is private; -- completion elided
>>
>> generic
>>    with procedure Visit (Object : in out T);
>> procedure Refresh (Object : in out T; Dirty : in out T) is
>> begin
>>    if Dirty then
>>       Visit (Object);
>>       Dirty := False;
>>    end if;
>> exception
>>    when others =>
>>       Dirty := True; -- warnings here
>>       raise;
>> end Refresh;
> 
> Poor design IMO. Either Dirty is a property of the object, then it must be 
> a member of T. Otherwise it is a result of Refresh for the caller, who 
> don't need Dirty flag anyway, because when exception propagates, he knows 
> that something was wrong.

Agree.  Reminds me of a "rescue clause" as in Eiffel DbC that
you use IFF trying to remove the cause of the previous exception
and then trying the subp/block again. If there is no need to retry and
you just record some state in Dirty, then why raise?  OTOH, if the
caller needs to be informed about the nature of the exception,
that information could be part of a suitably defined state parameter.