CVS difference for ai05s/ai05-0202-1.txt

--- ai05s/ai05-0202-1.txt	2010/02/23 07:31:06	1.2
+++ ai05s/ai05-0202-1.txt	2011/02/15 04:48:34	1.3
@@ -1,4 +1,4 @@
-!standard  C.7.3(8/2)                               10-02-12    AI05-0202-1/01
+!standard  C.7.3(8/2)                               11-02-12    AI05-0202-1/02
 !class binding interpretation 10-02-12
 !status work item 10-02-12
 !status received 09-09-24
@@ -8,8 +8,9 @@
 !subject Task_Termination and Exceptions raised during finalization
 !summary
 
-Exceptions raised during finalization have no effect on the Cause of termination
-of a task.
+Exceptions raised during finalization of a task result in the
+Cause of its termination being reported as Unhandled_Exception,
+with an exception occurrence that identifies Program_Error.
 
 !question
 
@@ -41,21 +42,23 @@
 
 Modify C.7.3(8/2):
 
-The type Termination_Handler identifies a protected procedure to be executed
-by the implementation when a task terminates. Such a protected procedure is
-called a handler. In all cases T identifies the task that is terminating. If
-the task terminates due to completing the last statement of its body, or as
-a result of waiting on a terminate alternative, then Cause is set to Normal
-and X is set to Null_Occurrence. If the task terminates because it is being
-aborted, then Cause is set to Abnormal and X is set to Null_Occurrence. If
-the task terminates because of an exception raised by the execution of its
-task_body, then Cause is set to Unhandled_Exception and X is set to the
-associated exception occurrence. {In any case, an exception raised by the
-finalization of the task does not change Cause or X.}
+  The type Termination_Handler identifies a protected procedure to be
+  executed by the implementation when a task terminates. Such a
+  protected procedure is called a handler. In all cases T identifies the
+  task that is terminating. If the task terminates due to completing the
+  last statement of its body, or as a result of waiting on a terminate
+  alternative, {and the finalization of the task body master completes
+  normally,} then Cause is set to Normal and X is set to
+  Null_Occurrence. If the task terminates because it is being aborted,
+  then Cause is set to Abnormal and X is set to Null_Occurrence. If the
+  task terminates because of an exception raised by the execution of its
+  task_body, then Cause is set to Unhandled_Exception and X is set to
+  the associated exception occurrence. {If the task completes normally
+  or due to a terminate alternative, but finalization of the task
+  propagates an exception, then Cause is set to Unhandled_Exception and
+  X is an exception occurrence that identifies the Program_Error
+  exception.}
 
-[Editor's note: What the heck kind of name for a parameter is X? How did that
-get through review?? Oh well, too late to change that now.]
-
 !discussion
 
 The only exception that can be propagated by a failed Finalize routine is
@@ -63,26 +66,13 @@
 an exception (it will propagate Program_Error to any queued callers).
 Waiting for tasks cannot propagate an exception (but we might wait forever).
 Nothing else happens during a finalization.
-
-So the author believes that this boils down to the Program_Error propagated
-by a failed finalization.
-
-In any case, the primary purpose of the handlers is to report the otherwise
-silent termination of a task. The "cause" is a secondary feature, so it isn't
-critical to be able to tell between the many kinds of failure. But it is
-important to have a consistent definition.
-
-The definition of Cause is primarily to report why the task itself terminated.
-The termination of the task definitely was *not* caused by whatever happens
-during finalization. When a task fails, it may cause cascading errors during
-finalization, but that is likely to be much less interesting information.
-Thus we define that whatever happens in the finalization code is ignored for
-the purposes of setting Cause.
-
-This does have the weird effect of reporting Normal termination for a task
-whose finalization raises an exception, but the seems better than obscuring
-the reason that the task_body completed and terminated.
 
+To avoid reporting Normal in the case of failed finalization, we specify that
+failed finalization results in Unhandled_Exception and an occurrence that
+identifies Program_Error. We don't specify anthing else about the occurrence,
+as there is no desire to overspecify the implementation and perhaps thereby
+introduce undesirable distributed overhead on behalf of this very unusual
+circumstance.
 
 --!corrigendum 3.9.3(4/2)