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 Path: g2news1.google.com!news4.google.com!out02a.usenetserver.com!news.usenetserver.com!in04.usenetserver.com!news.usenetserver.com!newsfeed.yul.equant.net!newspeer.monmouth.com!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: contracted exceptions Date: Sat, 09 Jun 2007 14:04:23 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1181165630.012508.55290@i38g2000prf.googlegroups.com> <19fxsxv1god43$.1pqq8vgfu2itn$.dlg@40tude.net> <4669BBBB.8040806@obry.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: pcls6.std.com 1181412263 8021 192.74.137.71 (9 Jun 2007 18:04:23 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 9 Jun 2007 18:04:23 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:62uxL24Ktnpc4CbsqTidA0/XXZQ= Xref: g2news1.google.com comp.lang.ada:16135 Date: 2007-06-09T14:04:23-04:00 List-Id: "Randy Brukardt" writes: > "Pascal Obry" wrote in message > news:4669BBBB.8040806@obry.net... >> Stefan Lucks a �crit : >> > If a task fails to handle an exception raised somewhere inside, the task >> > silently dies -- without notifying anyone. Enforcing the subprograms >> > used by the task to precisely specify "this subprogram might raise these >> > exceptions and none else" would help a lot ... >> >> That's really different. And think about it, since a task is mapped to a >> thread which comes with its own stack... who could possibly handle this >> exception ? > > And more importantly, where would it be raised? If it was raised in the > parent task, that could happen anywhere, which would be a design nightmare > (a different nightmare than the current one, anyway). I can think of lots of rules that are not perfect, but are at least superior to the existing rule of silently ignoring the exception. The simplest would be to terminate the entire program immediately. And print an error message on systems where that makes sense. Ada has no way to terminate the whole program (i.e. call "exit"), but it should. Or just print an error message. Or raise Program_Error in the parent task at the point where that task awaits its dependents. Option: abort all the siblings as well. Or put the task to sleep, so the parent waits forever (and the programmer has to debug a "deadlock"). >> And note that in Ada 2005 you can use Ada.Task_Termination to register >> termination notifications. > > It's unfortunate that the default isn't to notify someone, however. Right. Ada.Task_Termination is another way, and the default should be to raise alarms of some sort. >...Worse, > this interface might not work in out-of-memory circumstances (one of the > most common reasons for task failure, at least in Janus/Ada programs where > the default stack size is rather small). Right, out-of-memory is a difficult issue. I don't know of any language that solves it well. You might think you could do: task body T is begin declare ... begin ... exception when others => ... end; end T; and carefully prove that the handler code cannot raise any exceptions itself. But you can't prove the absense of Storage_Error in Ada. My solution: allow the programmer to declare that certain regions of code cannot run out of memory. The compiler must reserve enough memory (and if can't, then raise S_E before entering that region). Of course, what you can do in such a region is implementation dependent. This would make life difficult for compilers that generate C, or any other target language that doesn't have sufficient control over memory use. :-( - Bob