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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Interesting AWS error. Date: Wed, 10 Dec 2014 16:41:39 +0100 Organization: cbb software GmbH Message-ID: References: <1i3v7l7hdsio7$.13u4nz42lklre$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: YGNMlxhiQ90vAyH0QA4qPw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:23937 Date: 2014-12-10T16:41:39+01:00 List-Id: On Wed, 10 Dec 2014 08:26:29 -0700, Shark8 wrote: > On 10-Dec-14 01:43, Dmitry A. Kazakov wrote: >> Consider this scenario, you get an exception somewhere. That winds the >> stack up. This causes some controlled object to finalize in some block. If >> the exception is bad, the finalization fails [*] and a second exception is >> propagated. Upon leaving Finalize that exception is converted to a third >> exception, the Program_Error one. This could repeat itself many times, so >> what you get could have nothing to do with the original issue at all. > > Is this problem (finalize exception propagation) due to the language, > making it difficult/impossible to get right? Or is it due to the > architecture of the compiler? Or is it due to the compiler's > code-generation? {Or a combination of all the above?} It is a combination. There is really little to do when an exception is propagated out of Finalize. Maybe it should rather abort the task at once than rolling the snowball. And exceptions lacking contracts making it difficult to detect the cases when Finalize is not exception-safe. This hits me very often. >> It likely is an induced error, the original one is swallowed. You should >> use GNAT exception tracing in order to track the original problem down, >> which could be an induced one as well. > > I'll see if I can get exception-tracing to work; given that the error > w/o it points to "declare" I'm not overly confident the results will be > sensible, but we shall see. See GNAT.Exception_Traces. It is a very helpful thing. Then, AWS is not your code, but in critical parts of your code, you can also make use of GNAT.Most_Recent_Exception. E.g. when you enter a Finalize, you can log the exception occurrence which caused the object to go away. Of course, it is all GNAT-specific. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de