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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!esY63sJc+00ALEoUyxrwTg.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Discriminants or Constructor Function for Limited Types Date: Mon, 9 May 2022 11:45:33 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <0b4ddd38-1f19-44fe-acd9-43a316ec9d29n@googlegroups.com> <7puf7h59k2e2ns66918i95s847na2b8num@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: gioia.aioe.org; logging-data="40811"; posting-host="esY63sJc+00ALEoUyxrwTg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:63833 List-Id: 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