> The internal SRI software exception was caused during execution
>     of a data conversion from 64-bit floating point to 16-bit signed
>     integer value. The floating point number which was converted had
>     a value greater than what could be represented by a 16-bit
>     signed integer. This resulted in an Operand Error. The data
>     conversion instructions (in Ada code) were not protected from
>     causing an Operand Error,

     I tell that, for anyone who has a little of experience with Ada, 
the concepts of a 64-bit floating point doesn't exist and the concept of 
a 16-bit integer is only used when dealing with matching with an 
hardware interface, which was apparently not the case here. These 
concepts are imported from cpu hardware or from another language. Ada 
separates the programmer from implementation concerns. The conclusion I 
draw from this report is that the author of the report thinks with 
concepts which are foreign to the language and it seems the author of 
the program did the same.

     My personnal understanding is this was a total jeopardy: the 
company in charge produced a code in Ada because it was a requirement, 
but they didn't hire a skilled Ada programmer; nobody reviewed the code, 
which was translated from another language to Ada, with a very poor 
result; and even the authors of the report lack a basic knowledge of the 
language.

     And I insist: there are no such loosy things as implicit 
conversions in Ada, whatever the word you use to express the concept. 
You consider natural to program with short int or double and have 
implicit conversions in pretty much every expression and assignment. All 
of this just doesn't exist in Ada. You can force (you don't even imagine 
down to which details) the way a variable is implemented, but you do it 
when it makes sense.

     For what regards raising an exception, what else could be done? At 
least it triggered autodestruction, which is for sure better than 
heading to a random direction. This is also part of Ada's rationale: 
always check everything (as much as possible at compile time, else at 
run time) and never silently ignore an error because it could produce 
unpredictable effects; raising an exception is always better. You can 
catch exceptions at some higher level of course - if you know how to 
recover.

     Didier