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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,f039470e8f537101
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-07-23 10:48:35 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!feed2.news.rcn.net!rcn!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!spool.news.uu.net!not-for-mail
Date: Wed, 23 Jul 2003 13:48:33 -0400
From: Hyman Rosen <hyrosen@mail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5a) Gecko/20030611 Thunderbird/0.1a
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Ariane5 FAQ
References: <1058799152.775376@master.nyc.kbcfp.com>
 <bfh2gb$eeiv4$1@ID-175126.news.uni-berlin.de>
 <1058810510.375902@master.nyc.kbcfp.com>
 <bfhaed$e786b$1@ID-175126.news.uni-berlin.de>
 <1058813341.841940@master.nyc.kbcfp.com>
 <bfhe55$eqglr$1@ID-175126.news.uni-berlin.de>
 <1058816605.566685@master.nyc.kbcfp.com>
 <bfhjjr$eftm1$1@ID-175126.news.uni-berlin.de>
 <AY0Ta.14787$0F4.7550@nwrdny02.gnilink.net>
 <PmiTa.119324$ye4.85458@sccrnsc01> <1058969472.350716@master.nyc.kbcfp.com>
 <bfm8gm$ggeke$2@ID-175126.news.uni-berlin.de>
In-Reply-To: <bfm8gm$ggeke$2@ID-175126.news.uni-berlin.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Organization: KBC Financial Products
Message-ID: <1058982513.114816@master.nyc.kbcfp.com>
Cache-Post-Path: master.nyc.kbcfp.com!unknown@nightcrawler.nyc.kbcfp.com
X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/)
NNTP-Posting-Host: 204.253.250.10
X-Trace: 1058982513  26823 204.253.250.10
Xref: archiver1.google.com comp.lang.ada:40714
Date: 2003-07-23T13:48:33-04:00
List-Id: <comp.lang.ada>

Vinzent Hoefler wrote:
> I don't see, how someone can avoid such problem.

By having lots of meetings, and coming up with a
definite specification for what to do. The result
will be some hard numbers - if the reading is less
than this, it's good, otherwise it's suspect. Then
the code is written to implement the decision.

It's also perfectly valid to say "go ahead and write
this code as if this variable will never exceed this
value". The first way detects the problem at the
point where the bad value is noticed, while the second
way propogates the bad value through the program, so
that it will behave in some arbitrary way.

Now, often that arbitrary way will in retrospect be
exactly what you wanted, while the range check could
cause an entire abort, so it's not a given which
approach to use. In the Ariane 5 case, it turned out
that this approach caused an unhappy outcome.