Re: Interesting AWS error.

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

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