watro@faron.UUCP (Ronald J. Watro) (05/02/87)
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