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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,801ae1434b38d9bc,start
X-Google-Attributes: gid103376,public
From: Ken Garlington <kennieg@nospam.flash.net>
Subject: Handling Exceptions
Date: 1998/02/12
Message-ID: <34E3A7EE.45B5@nospam.flash.net>#1/1
X-Deja-AN: 324620408
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Organization: Flashnet Communications, http://www.flash.net
Mime-Version: 1.0
Reply-To: Ken.Garlington@nospam.computer.org
Newsgroups: comp.lang.ada
Date: 1998-02-12T00:00:00+00:00
List-Id: <comp.lang.ada>


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 )