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 07:06:59 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 <ada.rocks@jlfencey.com>
Newsgroups: comp.lang.ada
Subject: Re: status of PL/I as a viable language
Date: Fri, 21 Feb 2003 10:05:12 -0500
Organization: JeLlyFish software
Message-ID: <87f53b.8la.ln@jellix.jlfencey.com>
References: <mHZ0a.42983$jM5.108891@newsfeeds.bigpond.com>
 <nRg1a.190899$HG.32437469@news4.srv.hcvlny.cv.net>
 <3E51908E.9CCA3412@adaworks.com>
 <8Gh4a.7455$_c6.743959@newsread2.prod.itd.earthlink.net>
 <3E51ABCE.5491B9A2@adaworks.com> <b2spe6$p23$1@helle.btinternet.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> <oprkxqhntnmzo9uz@news.vol.cz>
 <1045839283.86671@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 1045840018 52826946 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:34343
Date: 2003-02-21T10:05:12-05:00
List-Id: <comp.lang.ada>

Hyman Rosen wrote:

> I've mentioned this many times before. Language checks such as
> bounds checking, pointer checking, and overflow checking are
> fine for testing. But when the application is released, it is
> better to disable such checks in cases where continued operation
> is important, because it's more likely that a program which
> "gets away" with making such an error can keep working,

Or just overwrite some more important data so that the device still 
seems to work but gives wrong results.

> whereas detecting the error will just blow the program away.

Or the other way around. Depends.

The only solution would be an error free program and even that cannot 
protect you from malfunctioning hardware. Better to catch the exception 
and turn on the backup system then.


Vinzent.

-- 
"Water?  Never touch the stuff!  Fish fuck in it."
                -- W. C. Fields