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 10:44:19 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsmi-us.news.garr.it!NewsITBone-GARR!news.mailgate.org!newsfeed.stueberl.de!newsfeed.vmunix.org!feed.news.nacamar.de!newsfeed.freenet.de!news-feed1.de1.concert.net!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 13:42:22 -0500 Organization: JeLlyFish software Message-ID: References: <3E51908E.9CCA3412@adaworks.com> <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> 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 1045853055 53332657 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:34362 Date: 2003-02-21T13:42:22-05:00 List-Id: Hyman Rosen wrote: > The problem is that we're talking about unanticipated > situations, so fallback handling is always going to be > iffy. The fallback handling for the Ariane 5 made it > blow up, after all. Mmh. Yes. As I said, the code in question was not wrong, it was just used in the wrong system. Would it have happened on Ariane 4, the fallback would have been the perfectly right decision. > I'm saying that things like buffer overruns and bad > memory accesses and to some extent arithmetic overflow > can be limited problems *can be*, yes. My experience says, most of the times they are not worse or better than any other kind of error. Real life example: The calculation for a list of machine parameters caused on overflow. It went through undetected and everything was fine just until the last set of parameter should have been activated. That did not happen, because it was not accessed anymore, it was out of the defined bounds. In the end this rendered the whole process useless. Catching the error beforehand would have caused the same uselessness just in another (time- and moneysaving) degree. The chance of detecting and fixing it earlier also would have been higher. I guess, we can both bring one example after the other, where on approach is better than the other. In the end, we both probably agree, such errors should not happen at all. > On the other hand, noticing the error will almost > certainly abort the operation, and since we're talking > about unanticipated errors, things may just come to a > halt. Or the big fat global exception handler just initiates a complete reboot or tries to get the thing into a safe state. Whatever you may do, it *can* under some circumstances be the wrong decision. > Whether this is desirable depends on the application. Yes. And IMO one of the main problem of deciding what might be better is: You never know until it actually happens. So I think, trying to minimize the number of possible errors is a good start. Vinzent. -- Nuke the gay, unborn, baby whales for Jesus.