Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!feeder.news.tin.it!spool.news.tin.it!not-for-mail From: "io_x" Newsgroups: comp.lang.java.programmer,comp.lang.c References: <36bp17tf79bhbd6hovf9srhmcs1jh1c040@4ax.com> <693db00d-83be-4830-a1fc-262d9d34d672@z15g2000pre.googlegroups.com> <9d33ce51-1f6a-4782-8098-a051456532ca@m6g2000prh.googlegroups.com> <8vlr17d90u9cb63hf64hhstaoamdgsb5je@4ax.com> Subject: Re: Arithmetic overflow checking Date: Fri, 15 Jul 2011 11:57:48 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Lines: 59 Message-ID: <4e200eac$0$44202$4fafbaef@reader1.news.tin.it> Organization: TIN.IT (http://www.tin.it) X-Comments: Please send technical notifications to newsmaster@tin.it NNTP-Posting-Host: 213.45.245.249 X-Trace: 1310723757 reader1.news.tin.it 44202 213.45.245.249:14525 X-Complaints-To: Please send abuse reports to abuse@retail.telecomitalia.it Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6204 comp.lang.c:8304 "Robert Wessel" ha scritto nel messaggio news:gn7v17d4ljhjsndhksgk4f1584a135u6cf@4ax.com... > On Wed, 13 Jul 2011 13:41:51 -0700, Keith Thompson > wrote: > >>markspace <-@.> writes: >>> On 7/13/2011 12:16 PM, lewbloch wrote: >>>> The lesson I derive is that nothing is too simple, trivial or obvious >>>> to overlook. >>> >>> >>> What I got from reading that is that the root problem was that the range >>> of values that the sensor was capable of producing was not understood. >>> Either or both physically producing, or would produce under normal (or >>> abnormal) system operation. >> >>As I recall, the range of values the sensor was capable of producing was >>understood correctly *when the code was written*. >> >>The problem is that the code was written for the Ariane 4. Management >>decided to re-use the same code, with no modifications, on the Ariane 5 >>-- on which the valid range of values from the sensor was quite >>different. >> >>> It was a failure to understand the the design, and its parameters. That >>> failure of understanding was then propagated down to the code level. >>> "We don't need to protect this because an out of range can't happen." >> >>Decisions had to be made when the code was written about which >>exceptions to handle, and which to assume couldn't happen. >>Handling them all wasn't an option because it would have slowed >>down the system enough so it wouldn't work at all. The particular >>decisions were correct for Ariane 4. > > > In a sense it's not that the exception was unhandled, but rather that > the exception was handled as a hardware failure, leading to the > shutdown of the inertial guidance computer. Of course the backup > guidance system keeled over at the same time (IIRC, the backup system > may have actually tripped off first by a few ms). > > So the problem was not so much the unhandled exception, but the > generation of the exception for the normal condition in the first > place. > > The real head-banger is that the code in question no longer did > anything useful on the Ariane 5. if i say something if you have a prog that 'can' fail the exception that make end the program is right because this point out one error to correct; if you have a prog can not fail it is better not raise the exception