Exception_Occurence and language designers

Exception_Occurence and language designers

[Mehdi Saada]

Curiously I find very interesting details of the norm, the inner working. Maybe I have a vocation of language lawyer ?
This time it's about exceptions.

Why have created both Exception_Identity and Exception_Occurence, often for the same subprograms ?
Especially, about Exception_Occurence:
Was it that the designers wanted to maintain compatibility, rather than breaking the last system and implementing something syntaxically closer to "subtype/type File_Not_found is Exception/new Exception; Not_Found_Error: File_Not_Found", a system closer to the type/subtype/instance model, but for exceptions ? Has it been thought about at one time ? To me it seems the Exception_Occurence'name declaration below, looks a lot like an object declaration, the exception Fine_Not_Found being a type.
Not the first case I thought it could be nicer to syntaxic constructs, rather than relying on predefined libraries (as with "controlled") ?

    when Not_Found_Error : File_Not_Found =>  Text_IO.Put_Line(Exceptions.Exception_Message(Not_Found_Error));

Re: Exception_Occurence and language designers

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> Why have created both Exception_Identity and Exception_Occurence,
> often for the same subprograms ?

An Exception_Identity identifies an exception which might happen.
An Exception_Occurrence is an exception that _has_ happened.

Re: Exception_Occurence and language designers

[Mehdi Saada]

but an "exception" is also an exception that might happen, at least when it's just declared. I still wonder why the same subprograms can take both Exception_Identity and Exception_Occurence, but not objects of the mere "exception" type. Mere exceptions are declared, but never taken as parameters like normal type instances are, like instances of Exception_Identity are.

Re: Exception_Occurence and language designers

[Dmitry A. Kazakov]

On 04/12/2017 15:00, Mehdi Saada wrote:
> but an "exception" is also an exception that might happen, at least 
> when it's just declared. I still wonder why the same subprograms can 
> take both Exception_Identity and Exception_Occurence, but not objects
> of the mere "exception" type. Mere exceptions are declared, but never
> taken as parameters like normal type instances are, like instances
> of Exception_Identity are.
In Ada 83 exception was not a first-class type. When Ada 95 added 
exception information it introduced Exception_Id to serve as a proper 
type for a class of exceptions and Exception_Occurrence to serve as 
exception instances.

In terms of tagged types it is like this:

    exception type              Foo : exception
    class-wide exception type = Exception_Occurence
    class-wide exception tag  = Exception_Id

Error'Exception_Identity is similar to Object'Tag.

There is no type-specific exception handling because you cannot define 
specific operations on an exception type:

    Foo : exception;
    procedure Bar (Error : Foo); -- This is illegal

You cannot declare type-specific exception instances either:

    Error : Foo; -- This is illegal

You can only declare class-wide instances in the form of exception handler:

    exception
       when Error : Foo | Baz =>

or explicitly:

    Error : Exception_Occurrence;

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

Re: Exception_Occurence and language designers

[Jeffrey R. Carter]

Exceptions are subject to Ada's visibility rules. In Ada 83, you could have

with Text_IO;
procedure Foobar is
    procedure Foo is
       Bar : exception;
    begin -- Foo
       raise Bar;
    end Foo;
begin -- Foobar
    Foo;
exception -- Foobar
when others => -- Bar is not visible here
    Text_IO.Put_Line (Item => "An exception occurred");
end Foobar;

Even though Bar is not visible outside Foo, it can still propagate out to Foobar 
and be handled by an others handler. It was impossible from that handler to know 
what has been handled.

Ada.Exceptions is a way to get around these limitations with minimum impact on 
backwards compatibility.

-- 
Jeff Carter
"I would never want to belong to any club that
would have someone like me for a member."
Annie Hall
41

Re: Exception_Occurence and language designers

[G. B.]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

> In Ada 83 exception was not a first-class type. 

Still isn’t.

> In terms of tagged types it is like this:
 
Exceptions may be understood to be part
of control structure. Doing so lets you see
them as neither objects nor subprograms.
So, in exceptional situations, the program
isn’t moving along *if*s and *loop*s and calls;
rather, a different mechanism of jumping is
triggered. You can handle the situation by
referring to its name, the exception’s, 
in a handler.

Other answers explain what to do if the
name is not in scope and how to print 
interesting information about what named
exception has caused the situation.

Re: Exception_Occurence and language designers

[Dmitry A. Kazakov]

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.

>> In terms of tagged types it is like this:
>   
> Exceptions may be understood to be part
> of control structure. Doing so lets you see
> them as neither objects nor subprograms.
> So, in exceptional situations, the program
> isn’t moving along *if*s and *loop*s and calls;
> rather, a different mechanism of jumping is
> triggered. You can handle the situation by
> referring to its name, the exception’s,
> in a handler.

That was Ada 83. Then it became clear that the exception should carry 
user-defined and other information. One could of course invent new 
syntax in order to query and handle that information (e.g. to save and 
restore exception). Ada 95 decided to use normal types and values 
instead. So Exception_Id, Exception_Occurrence, Raise_Exception, 
Save_Occurrence appeared.

> Other answers explain what to do if the
> name is not in scope and how to print
> interesting information about what named
> exception has caused the situation.

Exception_Id is like Ada.Tag, it never actually dies. That is the 
problem with making exception full types like in C++ (along with loosing 
nice Ada's flat exception catch syntax in favor of ugly C++'s 
walkthrough catcher).

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

Re: Exception_Occurence and language designers

[G. B.]

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


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

Re: Exception_Occurence and language designers

[Dmitry A. Kazakov]

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

Re: Exception_Occurence and language designers

[G. B.]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 05/12/2017 01:16, G. B. wrote:
>
>> How about this: the idea of creating normal,
>> typed objects as payload of wild jumps in
>> abnormal (exceptional) situations is rather optimistic.
> 
> The problem is upward closures. (...):
> 
> This works in C++ because there all types are global.

Creating objects in exceptional situations,
if meaningfully possible at all, will work in
C++ as long as the programmer manages
to copy the closure of data into the thrown
object, IINM.

>  Root_Exception_Attachment (...)
> 
> Apart from being not very useful and requiring a lot of overhead

If non-local jumps should pass information up the
call chain, then why not ask for a mechanism that
does just that? Trying to load exceptions with this
seems like misusing a concept.

Re: Exception_Occurence and language designers

[Dmitry A. Kazakov]

On 2017-12-05 21:05, G. B. wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 05/12/2017 01:16, G. B. wrote:
>>
>>> How about this: the idea of creating normal,
>>> typed objects as payload of wild jumps in
>>> abnormal (exceptional) situations is rather optimistic.
>>
>> The problem is upward closures. (...):
>>
>> This works in C++ because there all types are global.
> 
> Creating objects in exceptional situations,
> if meaningfully possible at all, will work in
> C++ as long as the programmer manages
> to copy the closure of data into the thrown
> object, IINM.

In Ada it necessarily becomes type closure. No way you could marry 
static typing with that.

>>   Root_Exception_Attachment (...)
>>
>> Apart from being not very useful and requiring a lot of overhead
> 
> If non-local jumps should pass information up the
> call chain, then why not ask for a mechanism that
> does just that?

Fine, if you manage to express that mechanism in terms of static strong 
typing, be my guest.

> Trying to load exceptions with this seems like misusing a concept.

Which is why Ada 95 didn't do that. Exception_Occurrence is a plain 
type, no magic.

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