Handling Exceptions

Handling Exceptions

[Ken Garlington]

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 )

Re: Handling Exceptions

[Nick Roberts]

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 <kennieg@nospam.flash.net> 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 )