Version 1.8 of ais/ai-00361.txt
!standard 11.3(2) 06-02-08 AI95-00361/06
!standard 11.3(3)
!standard 11.3(4)
!standard 11.4.1(10)
!class amendment 03-11-04
!status Amendment 200Y 04-01-13
!status WG9 Approved 04-06-18
!status ARG Approved 9-0-2 03-12-13
!status work item 03-11-04
!status received 03-11-04
!priority Medium
!difficulty Easy
!subject Raise with message
!summary
A string expression may be specified in a raise statement.
!problem
It would be nice to have a simpler syntax for specifying a message when raising
an exception, as the current method of calling Raise_Exception is quite
cumbersome.
!proposal
(See wording.)
!wording
Replace 11.3(2) by:
raise_statement ::= raise; |
raise exception_name [with string_expression];
Add after 11.3(3):
Name Resolution Rules
The expression, if any, in a raise_statement, is expected to be of type String.
Replace the second sentence of 11.3(4) by:
For the execution of a raise_statement with an exception_name, the named
exception is raised. If a string_expression is present, the expression is
evaluated and its value is associated with the exception occurrence.
Replace 11.4.1(10) by:
Raise_Exception raises a new occurrence of the identified exception.
Exception_Message returns the message associated with the given
Exception_Occurrence. For an occurrence raised by a call to
Raise_Exception, the message is the Message parameter passed to Raise_Exception.
For an occurrence raised by a raise_statement with an exception_name and a
string_expression, the message is the string_expression. For an occurrence
raised by a raise_statement with an exception_name but without a
string_expression, the message is a string giving implementation-defined
information about the exception occurrence.
Reraise_Occurrence reraises the specified exception occurrence.
!discussion
Ideally we would like to say that the expression is expected to be of any string
type. This would make it possible to raise exceptions with localized strings.
Unfortunately, this would make any literal ambiguous, and literals are expected
to be the most frequent expressions in raise-with statements. We don't want to
force users to use qualification all over the place.
!example
raise Not_Valid_Error with "Parent not valid";
!corrigendum 11.3(2)
Replace the paragraph:
raise_statement ::= raise [exception_name];
by:
raise_statement ::= raise; |
raise exception_name [with string_expression];
!corrigendum 11.3(3)
Insert after the paragraph:
The name, if any, in a raise_statement shall denote an exception.
A raise_statement with no exception_name (that is, a re-raise
statement) shall be within a handler, but not within a body enclosed by that
handler.
the new paragraph:
Name Resolution Rules
The expression, if any, in a raise_statement, is expected
to be of type String.
!corrigendum 11.3(4)
Replace the paragraph:
To raise an exception is to raise a new occurrence of that exception, as
explained in 11.4. For the execution of a raise_statement with an
exception_name, the named exception is raised. For the execution of
a re-raise statement, the exception occurrence that caused transfer of control
to the innermost enclosing handler is raised again.
by:
To raise an exception is to raise a new occurrence of that exception, as
explained in 11.4. For the execution of a raise_statement with an
exception_name, the named exception is raised. If a
string_expression is present, the expression is evaluated and its
value is associated with the exception occurrence. For the execution of a
re-raise statement, the exception occurrence that caused transfer of control to
the innermost enclosing handler is raised again.
!corrigendum 11.4.1(10)
Replace the paragraph:
Raise_Exception raises a new occurrence of the identified exception. In this
case, Exception_Message returns the Message parameter of Raise_Exception. For
a raise_statement with an exception_name, Exception_Message
returns implementation-defined information about the exception occurrence.
Reraise_Occurrence reraises the specified exception occurrence.
by:
Raise_Exception raises a new occurrence of the identified exception.
Exception_Message returns the message associated with the given
Exception_Occurrence. For an occurrence raised by a call to
Raise_Exception, the message is the Message parameter passed to Raise_Exception.
For the occurrence raised by a raise_statement with an
exception_name and a string_expression, the message is
the string_expression. For the occurrence raised by a
raise_statement with
an exception_name but without a string_expression,
the message is a string giving implementation-defined information about the
exception occurrence.
Reraise_Occurrence reraises the specified exception occurrence.
!ACATS test
An ACATS test (or additional test cases in the existing tests) should be
constructed to test this feature.
!appendix
From: Tucker Taft
Sent: Wednesday, February 8, 2006 4:43 PM
The Dynamic Semantics for "raise with string_expression"
never mentions evaluating the expression. It talks
about associating the value with the exception occurrence,
but doesn't explicitly say when it is evaluated:
11.3(4/2)
... If a string_expression is present, the value of the
expression is associated with the exception occurrence...
In almost all other circumstances of which I am aware,
we explicitly say "the expression is evaluated" or
equivalent as part of the dynamic semantics.
Worth fixing? Easiest fix is probably:
... If a string_expression is present, {the expression
is evaluated and its value} [the value of the expression]
is associated with the exception occurrence...
****************************************************************
From: Gary Dismukes
Sent: Wednesday, February 8, 2006 7:29 PM
...
> Worth fixing? Easiest fix is probably:
Yes, I'd say it's worth fixing.
> ... If a string_expression is present, {the expression
> is evaluated and its value} [the value of the expression]
> is associated with the exception occurrence...
Sounds good.
****************************************************************
From: Randy Brukardt
Sent: Wednesday, February 8, 2006 8:54 PM
This looks like an editorial change to me, and that can be done pretty much
at any time. (And I haven't finished the Amendment anyway, I have to wait
for the resolution of the various discussions.) So I'll make this change.
****************************************************************
From: Robert A. Duff
Sent: Thursday, February 9, 2006 7:46 AM
> The Dynamic Semantics for "raise with string_expression"
> never mentions evaluating the expression.
> Worth fixing?
We could fiddle with the document forever.
At some point we have to declare it done,
despite the fact that we know it contains bugs.
This particular bug is of little consequence.
It will not cause compilers to do the wrong thing.
It will not cause Ada programmers to be confused.
There's always Ada 201X...
****************************************************************
From: Randy Brukardt
Sent: Thursday, February 9, 2006 12:09 PM
> We could fiddle with the document forever.
> At some point we have to declare it done,
> despite the fact that we know it contains bugs.
According to Jim Moore, editorial fixes (those that don't change the
meaning) can be done to these documents at any time, up to ISO publication.
So we have a long time to be able to fix this sort of stuff.
This one is somewhat marginal to classify as editorial (in that I can't
imagine any other meaning, but maybe someone else case), so I wouldn't be
comfortable making this change after submission: but submission hasn't
happened yet, so we can (and should) still fix this sort of bug.
I don't think we should accept any additional major fixes at this point, no
matter what. (Currently open issues excepted, of course). So if that leaves
bugs, so be it. But there is no reason to not fix the missing package error,
to not fix the syntax of the example in D.5.2, nor to add the missing word
"evaluate", etc.
****************************************************************
From: Robert Dewar
Sent: Thursday, February 9, 2006 8:59 PM
>>Worth fixing?
I would just leave this, and if someone thinks it worth
the effort, fix it with a BI later. I would not make any
non-substantive changes to the document at this stage.
As Bob Duff says, "fixing" this "problem" will have
precisely zero impact.
****************************************************************
From: Robert Dewar
Sent: Thursday, February 9, 2006 9:01 PM
> This one is somewhat marginal to classify as editorial (in that I can't
> imagine any other meaning, but maybe someone else case), so I wouldn't be
> comfortable making this change after submission: but submission hasn't
> happened yet, so we can (and should) still fix this sort of bug.
I think we should either make another version because there is
an important reason to do so (e.g. accepting a substantive change
like the Canadian accept null proposal), or we should leave the
document completely untouched.
Having multiple versions that differ only in miscellaneous editorial
points that have no significant at all is not helpful.
****************************************************************
From: Tucker Taft
Sent: Thursday, February 9, 2006 9:55 PM
This seems essentially editorial, so it seems it is up
to the editor. I believe Randy is in the process of
doing final editorial changes; there is no "final version" yet,
as far as I know. Substantive changes are what we
are very much trying to avoid. Making editorial
changes seems to be at the discretion of the editor
until there is a "final final" version, and Randy implies
that even after that, obvious typos can be fixed.
****************************************************************
From: Randy Brukardt
Sent: Thursday, February 9, 2006 11:06 PM
> I think we should either make another version because there is
> an important reason to do so (e.g. accepting a substantive change
> like the Canadian accept null proposal), or we should leave the
> document completely untouched.
>
> Having multiple versions that differ only in miscellaneous editorial
> points that have no significant at all is not helpful.
I have no idea of what you are talking about at this time. The submission
draft (Draft 16) hasn't been finalized yet. Because of comments from the
various National Bodies, including various substantive ones, there is
roughly 4 pages of changes (which I've been carefully recording) from the
previous version. This is the version that is getting this change that
Tucker identified, and that certainly is going to be plenty different than
the previous draft 15.
Once the submission to WG 9 has been made, you'd have more of a point. But
I'll still be required by my Ada Europe contract to make carefully formatted
versions for them to publish. The PDF versions are sure to be updated at
that time; no one will want the version with the bad page breaks. And to the
extent that that work uncovers differences between the Amendment and the
AARM, the other formats of the AARM may be corrected.
****************************************************************
From: Robert Dewar
Sent: Friday, February 10, 2006 8:19 AM
Seems OK to me, but let's avoid a proliferation of different
versions of the RM that differ insubstantially.
****************************************************************
From: Erhard Ploedereder
Sent: Monday, February 13, 2006 11:32 AM
Let's avoid distributing anything that resembles an RM prematurely.
The Springer version will be the frozen version after JTC1 approval.
Publish earlier, any you do so at your own risk.
****************************************************************
From: Robert Dewar
Sent: Tuesday, February 14, 2006 5:28 AM
We already have!
I absolotely think we must have a preliminary RM, people are
using Ada 2005 today, and we want to encourage that. We do not
want people to lose interest while ISO fiddles around.
We just want to make sure we don't have too many different
versions that differ insubstantially.
****************************************************************
Questions? Ask the ACAA Technical Agent