From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!necntc!linus!faron!watro
From: watro@faron.UUCP (Ronald J. Watro)
Newsgroups: comp.lang.ada
Subject: Exception Propagation from Tasks
Message-ID: <113@faron.UUCP>
Date: Fri, 1-May-87 18:15:56 EDT
Article-I.D.: faron.113
Posted: Fri May  1 18:15:56 1987
Date-Received: Sun, 3-May-87 02:27:58 EDT
Reply-To: watro@faron.UUCP (Ronald J. Watro)
Distribution: world
Organization: The MITRE Corporation, Bedford MA
List-Id: <comp.lang.ada>

I am interested in opinions on the following ideas:

When an exception occurs in the body of a task (and the exception does
not occur during a rendezvous and there is no local handler which
applies), the exception causes the task to terminate but no propagation
of the exception to the master of the task occurs.  

The fact the unhandled exceptions can just disappear leaves
me with a queasy feeling.  Suppose I write a sequential program and
that I make no explicit use of exceptions.  I can then assume that any
error exceptions which occur will percolate out of the execution and be
reported to me.  If this sequential program is later optimized by
adding concurrency using tasks, errors may occur undetected.
Requiring programmers to add code to trap exceptions or requiring
the run time system to report all such errors back to the
operating system level are two possible solutions to this
problem, but perhaps there is a better solution.

When an exception occurs in the declarations of a task, it is
propagated to the master but in a changed form.  The exception
Tasking_Error is raised in the master before the master begins
execution of its body.  An obvious proposal to consider for exceptions
raised in task bodies is to propagate them to the master after it has
completed its execution.  Recall that after completion, the master
cannot terminate until all its dependent tasks have terminated (or have
a terminate alternative).  One question which would need to be answered
is what actions should the master be able to take when it receives an
exception after completion.  Even if all the master could do is
propagate the exception further, this would at least solve the problem
in the previous paragraph.  If the master could handle this exception
it would be even better.

I suggest that there be two predefined exceptions, Task_Init_Error
and Task_Body_Error.  The first would be raised before the master
begins execution to indicate errors in task initialization, while
the second would be raised in the master after completion to indicate
errors in task execution.  Task_Body_Error would be raised only after
all dependent tasks have terminated or reached terminate alternatives.
As for handling the new exception, perhaps we can let the master
do this in the usual way.  This would allow the master to begin
additional tasks, for example, or even let the master simply stop
the propagation of the exception, which would reproduce the
current Ada policy.

Ron Watro
faron!watro@mitre-bedford.ARPA