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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,801ae1434b38d9bc X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: Handling Exceptions Date: 1998/02/19 Message-ID: <01bd3cbe$c4e2e9a0$LocalHost@xhv46.dial.pipex.com>#1/1 X-Deja-AN: 326427214 Content-Transfer-Encoding: 7bit References: <34E3A7EE.45B5@nospam.flash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Organization: UUNet UK server (post doesn't reflect views of UUNet UK) Newsgroups: comp.lang.ada Date: 1998-02-19T00:00:00+00:00 List-Id: I was interested to see, on the site you mention, an example of a generic package for scaling a value of a particular floating-point type to a value of a particular integer type in a way which exactly spans the range of the integer type. This package contains an assertion that the integer type generic parameter should have at least two values, because less than two values would be silly. A fair assertion, on the face of it. BUT ... in fact, if you really think about it, this assertion is wrong! The reason why is that the assertion is at odds with the basic abstraction of the package. A single-value integer 'range' simply implies that that single value will always be returned: this situation does not transgress the basic abstraction of the package, so to call it an error situation is wrong. In particular, source text is sometimes generated automatically, and so (in a boundary case) a single-value integer type could be passed as a generic parameter, without there being any mistake. Without the unfortunate assertion, this single value would always be returned, and no harm done. As it is, the assertion (in debug mode) will fail, causing, at the very least, an annoyance. Of course, this is a tiny error in the way of things, but I think perhaps, it is still an apt illustration of how easy it is for errors to creep into software. It's also an example of how it is (at least) as easy for an error to get into an assertion as into the actual software itself. It is a quietly acknowledged fact that the most likely place to find errors, for a software project, is in the spec (whence false assertions and assumptions derive), rather than the software. I would wholeheartedly endorse the message that it is extremely foolish to take the attitude that merely raising an exception in an error situation is tantamount to 'handling' the error situation. For software which needs to have any degree of failure proofing, this is not good enough. The situation must be genuinely _handled_: it may or may not be propitious to use exceptions to do this, but this not the point. The point is that the situation should be dealt with, not just buck-passed. -- == Nick Roberts ================================================ == Croydon, UK =========================== == ================ == Proprietor, ThoughtWing Software ========== == Independent Software Development Consultant ====== == Nick.Roberts@dial.pipex.com ==== == Voicemail & Fax +44 181-405 1124 === == == == I live not in myself, but I become == === Portion of that around me; and to me == ==== High mountains are a feeling, but the hum == ======= Of human cities torture. =========== -- Byron [Childe Harold] Ken Garlington wrote in article <34E3A7EE.45B5@nospam.flash.net>... > An article in the most recent issue of Aviation Week > and Space Technology caused me to think once again > about the difficulty of choosing appropriate responses > to raised exceptions. > > An avaition display had been designed to perform an > automated reset when a particular parameter exceeded > a particular limit. The limit had been chosen to be > greater than any expected "real" value, such that only > system faults such as a corrupted message would reasonably > be the cause of the error. > > A commercial aircraft using this display excountered > extreme turbulence, and the aircraft rocked violently, > causing the parameter to go out of tolerance. The display > performed a reset as required -- causing the data on the > display to become unavailable to the pilot for the 2-3 > seconds (s)he needed it most, during the recovery from > the turbulence. > > Although the language used in the display is not discussed > in the article, I think Ada users can benefit from considering > the issues this incident highlights. It is also comparing and > contrasting this case and the Ariane 5 disaster. > > (More discussion on the problems of choosing good exception > handling is at > > http://www.flash.net/~kennieg/ariane.html#s3.3 )