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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!caip!sri-spam!nike!cad!ucbvax!MIT-MULTICS.ARPA!Brosgol From: Brosgol@MIT-MULTICS.ARPA Newsgroups: net.lang.ada Subject: Re: Propagation of exceptions raised wit Message-ID: <860609140637.124593@MIT-MULTICS.ARPA> Date: Mon, 9-Jun-86 10:06:00 EDT Article-I.D.: MIT-MULT.860609140637.124593 Posted: Mon Jun 9 10:06:00 1986 Date-Received: Wed, 11-Jun-86 00:24:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: With respect to some recent interchanges on exception propagation and tasks... Long ago and far away there was a mechanism in Ada known as the 'FAILURE exception. It was an attribute of a task, and the idea was that by raising FOO'FAILURE you could let task FOO carry out its "last wishes" before its demise. Kind of a graceful abort. Well, it was nice in theory but proved to be devilish in practice -- it turned out to be impossible to program task FOO so that it could respond to an exception that was raised asynchronously. So 'FAILURE is now an archeological curiosity rather than a language feature. The problems with asynchronous exceptions are why exceptions do not propagate out of tasks. That is, there is no way of knowing where the parent task is when the child task raises the exception. Asynchronous exception raising would be an unreliable and hard to implement means of synchronization. So, sorry about the lack of symmetry between tasks and other units with respect to exception propagation, but tasks are different in an essential way here. If a task must communicate its failure to complete normally, then it should do so via the recommended synchronization technique -- rendezvous. (If you like to live dangerously and erroneously I guess you could also use shared variables.) If it is important for a parent task to know that its children have completed successfully, then the parent should rendezvous with each child when it (the parent) has finished its own business. Make sure that each child has a "when others ==> accept DONE(...)" where DONE has an out parameter that reflects the child's status. Each child must also accept DONE when it completes normally. The program invocation example mentioned by Dave Emery looks like a red herring as far as the exception propagation issue is concerned. Program invocation does not follow Ada tasking semantics (the invoked program and the invoker have no common address space, and the invokee is not a child task of the invoker -- the invoker does not sit suspended waiting for the invokee to complete). So I don't see that it is relevant to the issue of whether exceptions should or shouldn't propagate. -Ben Brosgol