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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8893269a4640c798 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-25 19:59:15 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!in.100proofnews.com!in.100proofnews.com!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" Newsgroups: comp.lang.ada References: <3F1C4DA6.3070405@attbi.com> <3F1D29E8.60107@noplace.com> <3F1D2FDC.1070402@noplace.com> <3F1DC75A.5050300@noplace.com> <87oezm9lar.fsf@inf.enst.fr> <3F1E7E1E.8090302@noplace.com> Subject: Re: terminate applications X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Date: Fri, 25 Jul 2003 22:58:53 -0400 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1059188665 24.150.168.167 (Fri, 25 Jul 2003 23:04:25 EDT) NNTP-Posting-Date: Fri, 25 Jul 2003 23:04:25 EDT Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:40821 Date: 2003-07-25T22:58:53-04:00 List-Id: "Dmitry A. Kazakov" wrote in message news:bluvhvsr5kagtd9ksjdlpasf2iamcgu67v@4ax.com... > On Thu, 24 Jul 2003 10:54:51 -0400, "Warren W. Gay VE3WWG" > wrote: > > >"Dmitry A. Kazakov" wrote in message news:ek2vhv4qcbtj4hspi2c0lojbtsh1baldql@4ax.com... > >> On Thu, 24 Jul 2003 01:47:36 GMT, Hyman Rosen > >> wrote: > >> Probably the programmer has not done his homework. In a properly > >> designed system there is no need in things like that. Even less Ada > >> standard should encourage them. > > > >Perhaps, and perhaps not because it is due to an O/S bug where it > >blocks on an O/S call when it should return an error. Things are not > >always so cut and dry. > > The point is why your code should behave as Windows does? An Ada > application can be and should be designed in a way allowing a graceful > exit provided that underlying OS is OK. I am not disputing that good design should be used, and I doubt the OP was either. However, there are practical situations outside of rockets and weapons where a "kill -9" feature is useful (debugging has already been suggested as one good one). > Now, how this can support any need to incorporate that buggy API into > the standard? You are labelling it a "buggy API". I see this as a legitamate function. For example, if an some internal assertion fails, it may be highly desireable to have the whole application be "canned" immediately, without a shutdown (which might inflict further damage). The problem as I see it, is that there is a very strong tension between the embedded/rocket/life-threatening developers and those that write much more mundane applications. I feel this same tension is rearing its head here. If Ada is to gain wider exceptance, you need to take those blinkers off. ;-) The embedded people don't want it because they don't want it used (to that I say fine, don't use it!) Ravenscar avoids a large portion of Ada features that it considers "unsafe". What harm can one more "feature" bring if it is correctly documented? To use an analogy you want to ban emergency brakes because they're weak, and almost useless. Yet every car in North America must have one. I think having the choice of an emergency brake makes sense. No one is suggesting that you should use it, or that it be recommended. It merely should exist to offer a choice for those practical situations where it might be useful and valid. > Let operation F yelds an unpredictable result. Why one would like to > call F? It would make WHAT? Keep in mind that many API calls are made underneath the hood, and by libraries. The programmer is not always directly involved in the problem. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg