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,e6a2e4a4c0d7d8a6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-21 12:39:17 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!firewall.mdc-dayton.COM!not-for-mail From: Vinzent Hoefler Newsgroups: comp.lang.ada Subject: Re: status of PL/I as a viable language Date: Fri, 21 Feb 2003 15:37:37 -0500 Organization: JeLlyFish software Message-ID: References: <8Gh4a.7455$_c6.743959@newsread2.prod.itd.earthlink.net> <3E51ABCE.5491B9A2@adaworks.com> <3E5273DE.2050206@cox.net> <3E531E6F.BDFB2599@adaworks.com> <3E546C45.4010406@cox.net> <3E54F926.441D5BB5@adaworks.com> <1045763933.848350@master.nyc.kbcfp.com> <42EA55F4BE83950E.F1DA277C2FDC157B.C804C1C52FE95D65@lp.airnews.net> <1045769690.126389@master.nyc.kbcfp.com> <2lb33b.7d6.ln@jellix.jlfencey.com> <1045772065.590669@master.nyc.kbcfp.com> <1045839283.86671@master.nyc.kbcfp.com> <1045845919.135559@master.nyc.kbcfp.com> <1045851033.454019@master.nyc.kbcfp.com> <1045853548.242365@master.nyc.kbcfp.com> <2du53b.r6p.ln@jellix.jlfencey.com> <1045857476.256710@master.nyc.kbcfp.com> NNTP-Posting-Host: firewall.mdc-dayton.com (12.161.103.180) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1045859956 53318717 12.161.103.180 (16 [175126]) X-Orig-Path: jellix.jlfencey.com!nobody X-Newsreader: KCNews v0.19b (CAOS 4.1) X-Phone: +1-937-271-7158 X-Homepage: http://jlfencey.com Xref: archiver1.google.com comp.lang.ada:34382 Date: 2003-02-21T15:37:37-05:00 List-Id: Hyman Rosen wrote: > Vinzent Hoefler wrote: >> ACK. But even on one single system you cannot say if a better >> approach would be ignoring or eventually handling the error. > > Pretty much by definition, no one expects these kinds > of errors, Well, I always expect errors. ;) > since they represent errors in the logic of > the code; you would just fix the logic, not add error > handlers. ACK. But to do that you should first know there is an error. > So the only thing you might have is some outer catch-all > handler which when invoked knows only that a disaster > has happened. So what do you do? Assume a bounded software > error and reboot, hoping the problem will go away? Assume > hardware failure, and go to your backups? Shut down? Such a "global failure" action highly depends on the system you are controlling. In the case of a nuclear plant a clean shutdown is probably the safest you can do, on a mobile phone simply restarting it could be a more appropiate decision. I think a significant part of the embedded systems out there currently use the approach to restart the system by using some watchdog timers or catch-all handlers and they just run fine with that. Needless to say, that such a decision might be the wrong one for the one particular "unthinkable" error. > Maybe it's just that someone miscounted the number of > letters in 'September' and has managed to overrun an > array by one character, and if you left it alone, the > program would keep going just fine. Maybe it overwrote some other parameter and now will do weird and possibly dangerous things. As I said, you never know until it actually happens. > There's no one right answer, but I'm firmly convinced > that ignoring errors is in the set of reasonable actions. Sometimes, yes. At least in Ada you always have the option to turn off all the checks if you really want to do so. But I think, as soon as such error is detected it should be fixed. So IMO it should be a strong requirement to either avoid the error completely by doing it correct the first time or detect such error at runtime in whatever system we are talking about. So, even in the case of letting the program go on after detecting such a violation, at least having a chance to log it and try to recover the system without a "real" dedicated error handler then *could* be fine. BTW, especially in the case of buffer overruns the system will crash anyway most of the times, because of a corrupted stack. Detecting the error before it screws everything up just makes the crash look more clean. ;) Vinzent. -- "I own my own body, but I share"