* Exception_Occurence and language designers
@ 2017-12-04 11:17 Mehdi Saada
2017-12-04 12:32 ` Simon Wright
2017-12-04 17:43 ` Jeffrey R. Carter
0 siblings, 2 replies; 11+ messages in thread
From: Mehdi Saada @ 2017-12-04 11:17 UTC (permalink / raw)
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));
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Exception_Occurence and language designers
2017-12-04 11:17 Exception_Occurence and language designers Mehdi Saada
@ 2017-12-04 12:32 ` Simon Wright
2017-12-04 14:00 ` Mehdi Saada
2017-12-04 17:43 ` Jeffrey R. Carter
1 sibling, 1 reply; 11+ messages in thread
From: Simon Wright @ 2017-12-04 12:32 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Exception_Occurence and language designers
2017-12-04 12:32 ` Simon Wright
@ 2017-12-04 14:00 ` Mehdi Saada
2017-12-04 14:31 ` Dmitry A. Kazakov
0 siblings, 1 reply; 11+ messages in thread
From: Mehdi Saada @ 2017-12-04 14:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Exception_Occurence and language designers
2017-12-04 14:00 ` Mehdi Saada
@ 2017-12-04 14:31 ` Dmitry A. Kazakov
2017-12-04 20:27 ` G. B.
0 siblings, 1 reply; 11+ messages in thread
From: Dmitry A. Kazakov @ 2017-12-04 14:31 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Exception_Occurence and language designers
2017-12-04 14:31 ` Dmitry A. Kazakov
@ 2017-12-04 20:27 ` G. B.
2017-12-04 20:55 ` Dmitry A. Kazakov
0 siblings, 1 reply; 11+ messages in thread
From: G. B. @ 2017-12-04 20:27 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Exception_Occurence and language designers
2017-12-04 20:27 ` G. B.
@ 2017-12-04 20:55 ` Dmitry A. Kazakov
2017-12-05 0:16 ` G. B.
0 siblings, 1 reply; 11+ messages in thread
From: Dmitry A. Kazakov @ 2017-12-04 20:55 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Exception_Occurence and language designers
2017-12-04 20:55 ` Dmitry A. Kazakov
@ 2017-12-05 0:16 ` G. B.
2017-12-05 8:35 ` Dmitry A. Kazakov
0 siblings, 1 reply; 11+ messages in thread
From: G. B. @ 2017-12-05 0:16 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Exception_Occurence and language designers
2017-12-05 0:16 ` G. B.
@ 2017-12-05 8:35 ` Dmitry A. Kazakov
2017-12-05 20:05 ` G. B.
0 siblings, 1 reply; 11+ messages in thread
From: Dmitry A. Kazakov @ 2017-12-05 8:35 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Exception_Occurence and language designers
2017-12-05 8:35 ` Dmitry A. Kazakov
@ 2017-12-05 20:05 ` G. B.
2017-12-05 20:48 ` Dmitry A. Kazakov
0 siblings, 1 reply; 11+ messages in thread
From: G. B. @ 2017-12-05 20:05 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Exception_Occurence and language designers
2017-12-05 20:05 ` G. B.
@ 2017-12-05 20:48 ` Dmitry A. Kazakov
0 siblings, 0 replies; 11+ messages in thread
From: Dmitry A. Kazakov @ 2017-12-05 20:48 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Exception_Occurence and language designers
2017-12-04 11:17 Exception_Occurence and language designers Mehdi Saada
2017-12-04 12:32 ` Simon Wright
@ 2017-12-04 17:43 ` Jeffrey R. Carter
1 sibling, 0 replies; 11+ messages in thread
From: Jeffrey R. Carter @ 2017-12-04 17:43 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-12-05 20:48 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-04 11:17 Exception_Occurence and language designers Mehdi Saada
2017-12-04 12:32 ` Simon Wright
2017-12-04 14:00 ` Mehdi Saada
2017-12-04 14:31 ` Dmitry A. Kazakov
2017-12-04 20:27 ` G. B.
2017-12-04 20:55 ` Dmitry A. Kazakov
2017-12-05 0:16 ` G. B.
2017-12-05 8:35 ` Dmitry A. Kazakov
2017-12-05 20:05 ` G. B.
2017-12-05 20:48 ` Dmitry A. Kazakov
2017-12-04 17:43 ` Jeffrey R. Carter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox