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!out01a.usenetserver.com!news.usenetserver.com!in04.usenetserver.com!news.usenetserver.com!nx01.iad01.newshosting.com!newshosting.com!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 16:43:08 -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> <1svme16jhnvn9$.j4urjfrb9d2i$.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1181421788 14155 192.74.137.71 (9 Jun 2007 20:43:08 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 9 Jun 2007 20:43:08 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:pVlY+gQmxc+8pYzb5XqEDBd7Apo= Xref: g2news1.google.com comp.lang.ada:16139 Date: 2007-06-09T16:43:08-04:00 List-Id: "Dmitry A. Kazakov" writes: > On Sat, 09 Jun 2007 14:04:23 -0400, Robert A Duff wrote: > >> 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. > > Terminate the parent task and that should become equivalent to "exit". Only if the parent task is the environment task. >> 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"). > > Maybe a sort of rendezvous on the predefined entry point with the parent > task? Maybe. Will you let me define entries of the environment task? ;-) >... 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. >> 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. > > Contracted exceptions? Let the user declare a subprogram with the contract > of no Storage_Error. Then the compiler checks that code and if it cannot > generate it in a way that would reserve all necessary memory before > entering the body, it would refuse to compile it. The implementation can always calculate (at link time) a worst-case amount of stack space that might be needed. The worst case might be the size of the address space in some cases (recursion, X:String:=..., etc). But the implementation cannot know statically whether that space will be available at run time, unless the entire program has that property (see SPARK). - Bob