From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	ip-172-31-65-14.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 required=3.0 tests=BAYES_00,NICE_REPLY_A
	autolearn=ham autolearn_force=no version=3.4.6
Path: eternal-september.org!reader02.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Discriminants or Constructor Function for Limited Types
Date: Mon, 9 May 2022 11:52:37 +0300
Organization: Tidorum Ltd
Message-ID: <jds32mF89prU1@mid.individual.net>
References: <0b4ddd38-1f19-44fe-acd9-43a316ec9d29n@googlegroups.com>
 <t4ti4a$s1u$1@gioia.aioe.org> <t4v3f0$lgb$1@dont-email.me>
 <t4vsfi$jtb$1@gioia.aioe.org> <t51v2o$enb$1@dont-email.me>
 <t52nd4$vj2$1@gioia.aioe.org> <t54osn$hqf$1@dont-email.me>
 <t5619r$10bc$1@gioia.aioe.org> <t57a3o$e76$1@dont-email.me>
 <t57vgs$4su$1@gioia.aioe.org> <7puf7h59k2e2ns66918i95s847na2b8num@4ax.com>
 <t590fe$3ef$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net 4IpEtMG7DTpfMAzdUXzrkAxYTcP84zd71LxZCn531g8I8hzu9b
Cancel-Lock: sha1:eShxIDgyQgvjoYGFbODkZza9GZU=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0)
 Gecko/20100101 Thunderbird/91.6.2
Content-Language: en-US
In-Reply-To: <t590fe$3ef$1@gioia.aioe.org>
Xref: reader02.eternal-september.org comp.lang.ada:63832
List-Id: <comp.lang.ada>

On 2022-05-08 21:00, Dmitry A. Kazakov wrote:
> On 2022-05-08 19:19, Doctor Who wrote:
>> On Sun, 8 May 2022 10:37:48 +0200, "Dmitry A. Kazakov"
> 
>>> Note, that your code is already unsafe because nobody knows if
>>> Create_or_Open_Output always opens the file and because there is no
>>> guarantee that the file is closed, while the design
>>>
>>>     declare
>>>        Output_File : Some_File_Type;
>>>     begin
>>>        Write_Output (Output_File, Data);
>>>     end;
>>>
>>> is 100% safe.
>>
>> Not in the case that your data space is exhausted, in that case
>> Write_Output will fail, because you have no checks of free space
>> before writing.
> 
> Upon a write error an exception will propagate and Output_File will go 
> out of the scope. The file will be closed and the exception will 
> continue its way. This is a safe behavior. Randy's code is unsafe and 
> requires catching and re-raising I/O exceptions in the client code.
> 
> This is an illustration why exceptions should be allowed to propagate 
> out of Finalize. When Finalize is used to close a handle this may fail 
> and there is no way to retry inside Finalize. The choice in Ada is 
> between aborting the program or sweeping the problem under the rug 
> ignoring the problem. A more sane approach would be to propagate 
> exception out of Finalize indicating the problem.


That might work if the scope that is being left has only one local 
object that needs finalization. But what if there are several, and the 
first Finalize propagates an expection? Should the remaining 
finalizations be skipped? That would not be right. But if the remaining 
finalizations are also attempted, their execution may run into problems 
because the first Finalize was not completed. Moreover, the remaining 
finalizations might also propagate one or more exceptions, so now there 
could be a whole set of different exception instances being propagated 
from all these finalizations. Which exception(s) should be retained and 
handled?

The term "can of worms" comes to mind...