comp.lang.ada
 help / color / mirror / Atom feed
From: dennison@telepath.com
Subject: Re: Exception Propagation
Date: 1999/06/08
Date: 1999-06-08T00:00:00+00:00	[thread overview]
Message-ID: <7jjbl4$n79$1@nnrp1.deja.com> (raw)
In-Reply-To: 375CC549.7EDFB885@spam.com

In article <375CC549.7EDFB885@spam.com>,
  spamwithchipsplease@spam.com wrote:
> dennison@telepath.com wrote:
> > That's the behavior I'd expect to see if the exception is occuring
in a
> > task. The whole program doesn't terminate just because one task
dies.
>
> This feature has escaped me, or I have forgot  ( RM95 11.4(4) ), I've
> also checked RM83 and found it to be a feature of that language
edition.
> I would rather the exception was propogated aleast this gives the
option
> of deciding whether  the program  terminates or not.

It wouldn't make much sense for that to happen. That would mean a task
(or the main routine) which had a child task could conveivably raise any
exception at any point in its execution. How would you write code to
handle and recover from that?

If you *do* want one task to raise an exception in another, just raise
the exception in a rendezvous. In that case, *both* tasks get the
exception.

>
> Given the RM specification, I think a mandatory "when others" task
level
> exception handler would be prudent.

That's what we do here, although there are probably situations where
that would be inadvisable. For example, OpenToken puts some extra
diagnotic information in Exception_Message whenever it (manually) raises
an exception. You wouldn't loose that with your exception handler, but
you would have to be smart enough to dump the exception information
somewhere before you leave the handler. Also, there's nothing stopping
some nice compiler vendor from dumping a stack trace for
exception-terminated tasks to stdout. But none of the ones I use are
that nice.

Following is one of my task outer exception handlers. Note that
"Log.Report" is a utility of ours that handles I/O in a task-safe manner
(Text_IO does not). Often task terminations cause cascading errors in
other tasks, which can cause contention for the I/O device. Its annoying
to get I/O exceptions when you should be getting details about the
*real* exception that caused the problem.:

   exception
      when Error : others =>
         Log.Report (Event => "Save_Restore.Data_Dispatcher terminated
due to " &
                     "unhandled exception." & Ada.Characters.Latin_1.Cr
&
                     Ada.Characters.Latin_1.Lf &
                     Ada.Exceptions.Exception_Information (Error),
                     Severity => Log.Error);

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.




  parent reply	other threads:[~1999-06-08  0:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-07  0:00 Exception Propagation Decker, Christian R
1999-06-07  0:00 ` dennison
1999-06-08  0:00   ` Glen
1999-06-08  0:00     ` Decker, Christian R
1999-06-08  0:00       ` Robert Dewar
1999-06-08  0:00       ` David C. Hoos, Sr.
1999-06-09  0:00       ` dennison
1999-06-14  0:00         ` Robert A Duff
1999-06-14  0:00           ` dennison
1999-06-15  0:00             ` Robert A Duff
1999-06-14  0:00           ` Bryce Bardin
1999-06-15  0:00           ` Dale Stanbrough
1999-06-15  0:00             ` Robert A Duff
1999-06-08  0:00     ` Robert Dewar
1999-06-09  0:00       ` Matthew Heaney
1999-06-08  0:00         ` R. Tim Coslet
1999-06-09  0:00         ` dennison
1999-06-09  0:00         ` Robert Dewar
1999-06-08  0:00     ` dennison [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-03-15 15:16 Exception propagation REH
2006-03-16 21:29 ` Ludovic Brenta
2006-03-16 22:19   ` REH
2006-03-16 22:51     ` Ludovic Brenta
2006-03-17  2:52       ` REH
2006-03-17 14:52         ` Georg Bauhaus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox