Version 1.2 of ai05s/ai05-0258-1.txt

Unformatted version of ai05s/ai05-0258-1.txt version 1.2
Other versions for file ai05s/ai05-0258-1.txt

!standard 11(2/3)          11-06-19 AI05-0258-1/01
!standard 11.4.1(10.1/3)
!class binding interpretation 11-06-19
!status work item 11-06-16
!status received 11-04-29
!priority Low
!difficulty Easy
!qualifier Omission
!subject Preserving information in an exception occurrence
!summary
** TBD.
!question
How many ways can an exception occurrence be created?
11(2/3) says that there are three "manners" that an exception can be raised.
11.4.1(10.1/3) talks about those and "other ways".
Is the list in 11(2/3) really exclusive? What happens for occurrences that are propagated between tasks, streamed in out (including by being marshalled across a remote call) and the like? For instance, is it OK to truncate the message when it is streamed?
This behavior was unspecified in Ada 2005 and before; did we mean to specify it?
Aside: there ought to be some wording that propagation preserves the contents of an exception occurrence.
!wording
** TBD
!discussion
!ACATS Test
** TBD.
!ASIS
** TBD.
!appendix

[Part of the editorial review of Erhard Ploedereder:]

11.4.1 10.1/3 penultimate sentence:
> For an occurrence originally raised for some other reason, the
> message is an unspecified string.

lazy wording "for some other reason". In "if things-go-bump then
raise fright; end if;"
things-go-bump is the reason for the exception, not the raise
statement.

According to 11 2/3(2.sentence) only implicit raises are left. If
indeed 9.5.2(24) is an extra case, 11 2/3 needs fixing, too, but
presumably it is but a propagation and hence not an extra case.
Footnote: I would prefer implementation-defined string. Oh well.

 Rewrite:
 -----
 For an occurrence originally raised by a language-defined check, the
 message is an unspecified string.

****************************************************************

From: Randy Brukardt
Sent: Friday, April 29, 2011 12:57 AM

> 11.4.1 10.1/3 penultimate sentence:
> > For an occurrence originally raised for some other reason, the
> > message is an unspecified string.
>
> lazy wording "for some other reason". In "if things-go-bump then raise
> fright; end if;"
> things-go-bump is the reason for the exception, not the raise
> statement.

Ugh, I suppose you are right.

> According to 11 2/3(2.sentence) only implicit raises are left. If
> indeed 9.5.2(24) is an extra case, 11 2/3 needs fixing, too, but
> presumably it is but a propagation and hence not an extra case.
> Footnote: I would prefer implementation-defined string. Oh well.

I don't quite buy this; anything that creates an occurrence has an
Exception_Message; it doesn't have to come from a raise of an exception. In
particular, it is possible to stream an occurrence, and I don't think the
language intended to require that the message is preserved unchanged. (Some
implementations truncate occurrences when they are copied or streamed; Janus/Ada
does that as the stack information could take up a huge amount of space
otherwise. Also, most exception messages are pointers (if static) until an
occurrence is copied; at that point the string has to be copied into the
occurrence [because we can't stream or do I/O on a pointer] and that truncates
it).

> Rewrite:
> -----
> For an occurrence originally raised by a language-defined check, the
> message is an unspecified string.

What about "new" occurrences from other source, at least WRT the current
program? The Ada 2005 wording definitely left that unspecified -- maybe it was
unintentional, but I don't want to change it without a full discussion (too late
for that now, I think). And the Adam question (in AI05-0043-1) seems legitimate;
9.5.2(24.b) says that this is a new occurrence; it is *not* considered
propagation. (Of course, AARM notes can be wrong, but it shows an intent.)

Indeed, I can't find anything that clearly says that propagation is required to
preserve the information in an occurrence. It seems like that should be said
somewhere. And I know that a reraise doesn't preserve an occurrence (at least in
Janus/Ada, it preserves parts of it, but it changes to reflect the reraise
location so that can be traced if necessary).

All-in-all, I don't think this is well-specified, and it hardly is worth
specifying much (do implementers really make these things useless because they
can?? I think it is more likely that they have a good reason for whatever they
do).

So, I'm making a minor tweak to this wording:

"For an occurrence originally raised in some other manner (including by the
failure of a language-defined check), the message is an unspecified string."

This isn't ideal, but this isn't worth a lot of effort, either.

****************************************************************

From: Erhard Ploedereder
Sent: Friday, April 29, 2011  4:17 AM

>"For an occurrence originally raised in some other manner (including by
>the  failure of a language-defined check), the message is an
>unspecified  string."

This is fine with me to cover my "things-go-bump"-remark.

But going that route, you also need to fix 11 2/3(2.sentence), since that one
only names three "manners", two of which are already covered in the sentences
preceeding this one. The only one left IS the failure of a language defined
check. 11 2/3 knows of no other manner, but by your argument it should.

****************************************************************


Questions? Ask the ACAA Technical Agent