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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,61e9062c1f23b9d5 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: contracted exceptions Date: Mon, 11 Jun 2007 14:18:05 -0500 Organization: Jacob's private Usenet server Message-ID: References: <1181165630.012508.55290@i38g2000prf.googlegroups.com> <19fxsxv1god43$.1pqq8vgfu2itn$.dlg@40tude.net> <4669BBBB.8040806@obry.net> <1svme16jhnvn9$.j4urjfrb9d2i$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1181589367 12547 69.95.181.76 (11 Jun 2007 19:16:07 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 11 Jun 2007 19:16:07 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Xref: g2news1.google.com comp.lang.ada:16162 Date: 2007-06-11T14:18:05-05:00 List-Id: "Robert A Duff" wrote in message news:wcck5uckgf7.fsf@shell01.TheWorld.com... ... > >... When the parent task accepts it, the exception is propagated out of > > the point of rendezvous in the parent, while the offending task finally > > rests in peace. When the parent task does not have this entry, then it > > (with all its children) is terminated. The process continues until > > rendezvous accepted or else death of the main task. > > Hmm. I guess the important thing is that the RM should define this > situation (exception propagation reaches the end of the task body) as an > error. That would encourage implementations to print error messages, > and debuggers to take control in such situations. > > Nothing prevents an implementation from printing an error message in > this situation already -- but it's not encouraged by the RM, any more > than encouraging the impl to print an error every time you assign 42 to > a variable. Ada 83 didn't have the concept of a bounded error, unfortunately, but this would seem to be a place where it could have been profitably used (raising Program_Error in the parent when waiting if the error is "detected"). The problem is that "when waiting" is already too late (usually my programs have deadlocked [or livelocked] by then). Some deadlocks are detected by our runtime, but of course livelocks are just a program hang with no indication why. I'm not convinced that there is any decent solution to this problem (printing messages can also deadlock the system, such as in the AdaIC webserver, which can run headless). In any case, I consider a task without a "when others" handler at the bottom (to do whatever is appropriate for the application) broken. Randy.