Re: Exception_Occurence and language designers

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

On 05/12/2017 01:16, G. B. wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 2017-12-04 21:27, G. B. wrote:
>>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>
>>>> In Ada 83 exception was not a first-class type.
>>>
>>> Still isn’t.
>>
>> But its "class-wide" type Exception_Occurrence is.
> 
> Exception_Occurrence feels like an enumeration, > to me at least, albeit of places in a program,
> thus of a rather special set of “values”.

"Enumeration" is Exception_Id.

>> Then it became clear that the exception should carry
>> user-defined and other information.
> 
> User-defined  information being strings, and
> other information being places to be embedded in
> strings, plus names of exceptions.
> 
> How about this: the idea of creating normal,
> typed objects as payload of wild jumps in
> abnormal (exceptional) situations is rather optimistic.

It is no matter what is freely typed, exception itself or the attached 
object. The problem is upward closures. Consider this:

    begin
       declare
          type Message_In_The_Bottle is new Controlled with ...;
          overriding procedure Finalize (E in out Message_In_The_Bottle);
          ...
       begin
          raise Hey with Message_In_The_Bottle'(...);
       end;
    exception
       when Error : Hey =>
          -- The object of a dead type here

This works in C++ because there all types are global.

One possible solution is to have the type Root_Exception_Attachment and 
derive every exception-attached object type from there. When the scope 
of the type is left upon exception propagation the object will be 
demoted to its still existing parent.

Apart from being not very useful and requiring a lot of overhead upon 
propagation, the existing Ada finalization model cannot handle this. The 
attached type's Finalize must be called upon conversion, but the 
parent's Finalize not. Then the added components must be finalized. Ada 
cannot such this now.

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