Re: Ada and Automotive Industry

[bobduff@world.std.com (Robert A Duff)]

In article <dewar.850929677@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>I disagree. It is often quite appropriate. Suppose you wrote a little
>package for giving saturation type semantics on ordinary arithmetic
>(overflow transfomed to max or min value as appropraite). You might
>still very well want to diagnose division by zero as an error, and
>raising constraint error would seem a perfectly good way of doing it.

OK, I'll buy that.  How about the following rule of thumb: It's OK to
raise C_E explicitly if the purpose is to indicate a bug in the program?
That is, if the exception occurs, you want the program to stop running,
not do any more damage, and go into the debugger and figure out what
went wrong (or use a stack traceback or whatever).  On the other hand,
if you want callers to *handle* the exception, and recover from it, you
ought to define your own exception name.

My reasoning is that handlers for C_E are questionable -- you probably
don't know for sure whether you got there from a range check, or your
explicit raise, so you have to worry about 11.6 issues.  It's possible,
but extremely tricky, to write correct exception handlers for C_E, given
11.6.  I suspect that few programmers understand 11.6 -- they just use a
simplified rule, which says "Don't handle C_E".  That's good -- it's
much simpler than the real 11.6 rules, and works fine in the vast
majority of cases.

(By the way, when I say "handle" here, I mean a handler that really
handles the situation -- not one that does clean-up-then-re-raise.)

So, in your divide-by-zero example, it seems fine to raise C_E, if you
believe that exception will always kill the program, if it happens.

- Bob