Version 1.1.1.1 of ais/ai-00169.txt

Unformatted version of ais/ai-00169.txt version 1.1.1.1
Other versions for file ais/ai-00169.txt

!standard 07.06.01 (14)          96-11-16 AI95-00169/00
!class binding interpretation 96-11-16
!status received 96-11-16
!priority Low
!difficulty Easy
!subject Exceptions raised by Adjust/Finalize -- Missing case
!summary 96-11-16
!question 96-11-16
!recommendation 96-11-16
!wording 96-11-16
!discussion 96-11-16
!appendix

!section 7.6.1(14)
!subject Exceptions raised by Adjust/Finalize -- Missing case
!reference RM95-7.6.1(14)
!from Vince Del Vecchio 96-10-18
!reference 1996-5731.a Vince Del Vecchio  1996-10-18>>
!discussion

RM 7.6.1(14ff) lists a variety of situations in which Finalize and Adjust
may raise exceptions, and the possible consequences.

It does not seem to indicate what happens when an exception is raised in
a Finalize which is part of the finalization of a master due to the most
normal type of completion--reaching the end of the execution.

It would probably make sense to finish finalizing the master, and
raise Program_Error in the enclosing construct, basically the way that
7.6.1(18) describes (except that there is less implementation dependency,
since the point after the finalization of the master currently being
finalized and the point at which normal execution would have continued
are roughly the same).

-Vince Del Vecchio
vdelvecc@inmet.com

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

!section 7.6.1(14)
!subject Exceptions raised by Adjust/Finalize -- Missing case
!reference RM95-7.6.1(14)
!reference 1996-5731.a Vince Del Vecchio  1996-10-18
!from Bob Duff
!reference 96-5733.a Robert A Duff 96-10-21>>
!discussion

> RM 7.6.1(14ff) lists a variety of situations in which Finalize and Adjust
> may raise exceptions, and the possible consequences.
>
> It does not seem to indicate what happens when an exception is raised in
> a Finalize which is part of the finalization of a master due to the most
> normal type of completion--reaching the end of the execution.

Indeed.

> It would probably make sense to finish finalizing the master, and
> raise Program_Error in the enclosing construct, basically the way that
> 7.6.1(18) describes (except that there is less implementation dependency,
> since the point after the finalization of the master currently being
> finalized and the point at which normal execution would have continued
> are roughly the same).

Yes.  (Kind of embarrassing!  A case where the devil is *not* in the
details, but in the usual line of business.  ;-))

- Bob

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

!section 7.6.1(14)
!subject Exceptions raised by Adjust/Finalize -- Missing case
!reference RM95-7.6.1(14)
!reference 1996-5731.a Vince Del Vecchio  1996-10-18
!from Vince Del Vecchio 96-10-30
!reference 1996-5736.a Vince Del Vecchio  1996-10-30>>
!discussion

There appear to be a few more problems in this area.

In addition to the missing fall-through case in paragraphs 15-20 of 7.6.1,
these paragraphs don't seem to describe what happens if the object
being finalized is an anonymous object which is not associated with
any particular master, as described in 7.6.1(13).  The real problem
paragraphs are where it talks about performing any other finalizations
for the same master, since it may not be a real master which is being
finalized.

This certainly needs to be answered in the fall-through case.  Presumably
the most reasonable thing to do would be to perform any other
finalizations "due to be performed" and then raise an exception, although
that "due to be performed" wording, which I think is a little bit vague
in the first place, may be even more vague here.  The decision about
where to raise the exception doesn't seem to hard.  "Where normal
execution would have continued" describes it fine.  It is also pretty
much immediately after finishing the finalization.

Anonymous objects created during an assignment statement are presumably
covered in paragraph 15.

It doesn't seem like there should be any anonymous objects to finalize
at an Unchecked_Deallocation (paragraph 17).

For paragraph 18, it is not entirely clear when a transfer of control
happens relative to the end of the statement which causes it.  The
finalization of anonymous objects (e.g. from the expression of an
"exit when") has to happen before the end of the statement, but the
finalization of any masters happens as part of the transfer of control.
If the transfer of control happens before the end of the statement,
then anonymous objects may be finalized as part of the transfer of
control.  At one point I thought that 5.1(14) seemed to imply that
the end of the statement (and its being left) preceded the transfer
of control (which might involve leaving other constructs).  I don't
see that now, but if this is in fact the case, then there shouldn't
be any anonymous objects to finalize in paragraph 18.

It is definitely possible that anonymous objects may be finalized due
to raising an exception (paragraph 19).  I'm not sure where the
exception should be raised.  Probably as soon as possible, which would
be within the master in which the anonymous object was created.

Paragraph 20 doesn't mention masters, and probably doesn't need
clarification.  In the event of an abort or terminate, just ignore
the exception and keep going.

Now for a not-entirely-related nit which you probably can't do anything
about:  The wording of paragraph 16 -- "For an Adjust invoked as part of
an assignment operation" -- makes it sound like there may be other cases
in which to worry about Adjust.  In fact, Adjusts can _only_ be invoked
as part of an assignment operation, so that clause is redundant (and
slightly confusing in its redundancy).

-Vince Del Vecchio
vdelvecc@inmet.com

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

!section 7.6.1(16)
!subject Exceptions raised by Adjust/Finalize -- Missing case
!reference RM95-7.6.1(16)
!reference 1996-5731.a Vince Del Vecchio  1996-10-18
!reference 1996-5736.a Vince Del Vecchio  1996-10-30
!from Robert I. Eachus 96-10-31
!reference 96-5739.a Robert I. Eachus 96-10-31>>

!discussion

   Vince Del Vecchio said:

 > Now for a not-entirely-related nit which you probably can't do anything
 > about:  The wording of paragraph 16 -- "For an Adjust invoked as part of
 > an assignment operation" -- makes it sound like there may be other cases
 > in which to worry about Adjust.  In fact, Adjusts can _only_ be invoked
 > as part of an assignment operation, so that clause is redundant (and
 > slightly confusing in its redundancy).

   Not slightly confusing--the user can explicitly call Adjust.  It is
a useful feature for debugging, if for no other reason.

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

!section 7.6.1(16)
!subject Exceptions raised by Adjust/Finalize -- Missing case
!reference RM95-7.6.1(16)
!reference 1996-5731.a Vince Del Vecchio  1996-10-18
!reference 1996-5736.a Vince Del Vecchio  1996-10-30
!reference 1996-5739.a Robert I. Eachus  1996-10-31
!from Vince Del Vecchio 96-10-31
!reference 1996-5740.a Vince Del Vecchio  1996-10-31>>
!discussion

>>>>> On Thu, 31 Oct 1996 14:23:53 GMT,
   "Robert I. Eachus" <eachus@spectre.mitre.org> said:

>    Not slightly confusing--the user can explicitly call Adjust.  It is
> a useful feature for debugging, if for no other reason.

Thank you for pointing this out; I missed that one.  So it's not redundant,
which means that there should be more clauses indicating what to do if
Adjust (and Finalize as well) propagate exceptions when called explicitly
from user code.  Alternatively, paragraph 14 could be modified to indicate
that such cases are not bounded errors.

(It had to be either one thing or the other--either redundant, or
indicative of a missing case.  I was just wrong about which it was. :-))

-Vince Del Vecchio

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

!section 7.6.1(14)
!subject Exceptions raised by Adjust/Finalize -- Missing case
!reference RM95-7.6.1(14)
!reference 1996-5731.a Vince Del Vecchio  1996-10-18
!reference 1996-5733.a Robert A Duff 96-10-21
!from Norman Cohen
!reference 96-5745.a Norman H. Cohen 96-11-7>>
!discussion

I agree that the 7.6.1(18) rule should apply in the fall-through case.  A
compelling argument, I think, is that adding a return statement to the end
of a procedure body or accept statement should not change its behavior, and
the behavior of an exception in finalization triggered by a return
statement is already specified by 7.6.1(18).

Bob Duff writes:

> Yes.  (Kind of embarrassing!  A case where the devil is *not* in
> the details, but in the
> usual line of business.  ;-))

Well, I'm embarassed too, because when I was trying to decipher the rules
in 7.6.1 for the revision of Ada as a Second Language, I somehow inferred a
rule that is not present in either the RM or AARM.  On page 656 I wrote:

If the construct was being exited because the end of its sequence of
statements was reached, or because the end of one of its handlers was
reached without another xception having been raised, Program_Error is
raised as if it were propagated by the construct being exited.

(I think that's equivalent to the 7.6.1(18) rule in this case.)  Perhaps
there WAS a clear rule in an earlier draft of RM9X, but it somehow got
lost, in which case we both have less reason to be embarassed.  Or perhaps
I got an unofficial interpretation from Bob or Tuck in private
correspondence.  Or perhaps I was off doing language design on my own. :-)

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

!section 7.6.1(16)
!subject Exceptions raised by Adjust/Finalize -- Missing case
!reference RM95-7.6.1(16)
!reference 1996-5731.a Vince Del Vecchio  1996-10-18
!reference 1996-5736.a Vince Del Vecchio  1996-10-30
!reference 1996-5739.a Robert I. Eachus  1996-10-31
!reference 1996-5740.a Vince Del Vecchio  1996-10-31
!from Bob Duff
!reference 96-5756.a Robert A Duff 96-11-8>>
!discussion

It seems to me that if an explicit call to Adjust or Finalize raises an
exception, it should *not* be a bounded error.  The exception should
just be propagated in the normal way, as for any other call.  The
exception should not be turned into Program_Error.  Anybody disagree
with that?  It seems what the user would expect, and it seems the
easiest to imlpement.

- Bob

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

!section 7.6.1(16)
!subject Exceptions raised by Adjust/Finalize -- Missing case
!reference RM95-7.6.1(16)
!reference 1996-5731.a Vince Del Vecchio  1996-10-18
!reference 1996-5736.a Vince Del Vecchio  1996-10-30
!reference 1996-5739.a Robert I. Eachus  1996-10-31
!reference 1996-5740.a Vince Del Vecchio  1996-10-31
!reference 1996-5756.a Robert A Duff 96-11-8
!from Randy Brukardt 96-11-10
!reference 96-5758.a Randy Brukardt  96-11-10>>
!discussion

>It seems to me that if an explicit call to Adjust or Finalize raises an
>exception, it should *not* be a bounded error.  The exception should
>just be propagated in the normal way, as for any other call.  The
>exception should not be turned into Program_Error.  Anybody disagree
>with that?  It seems what the user would expect, and it seems the
>easiest to imlpement.

Easiest to implement is an understatement.  I would expect that for most
compilers, Adjust and Finalize will be normal subprograms; all of the magic
will be in the calls to them (mostly from somewhere in the runtime system).
Trying to specially handle exceptions for explicit calls to the routines would
require detecting the routines and making the call in some special way.
That would be an awful lot of additional work for something uncommon AND
counter-intuitive.

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

Questions? Ask the ACAA Technical Agent