Re: Discriminants or Constructor Function for Limited Types

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2022-05-09 10:52, Niklas Holsti wrote:
> 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 is another design flaw that Finalize overrides rather than extends.

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

Sure, in a typical program you always have a snowball effect caused by 
an abnormal condition. It is the programmer's duty to sort the things 
out and the language must help.

What is the alternative, anyway?

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

In Ada the latest exception overrides the previous one. If you are 
asking whether a task should be able to determine if an exception is 
active and have access to its occurrence, my answer would be 
affirmative. One can also consider propagating exception inside the 
parent's finalization hooks, the same way we do with exceptions raised 
within a task rendezvous. One can also consider separate class-wide and 
type-specific finalization hooks etc.

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

Except that all worms are wiggling outside the can...

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