Re: Ada and Java. different behaviour. casting long to int problem.

[Hyman Rosen <hymie@prolifics.com>]

mike@ooo.nospam.com writes:
> In article <t71zf9cwuy.fsf@calumny.jyacc.com>, Hyman says...
> >But no one generally expects arithmetic overflow exceptions, so no one
> >writes exception handlers for them. 
> You do not need to put special handler for this, use a general, catch all
> handler. Then if interested, check for the specific handler your care about
> handling.

We're going in circles here. My contention is that because no one expects
these errors, the exception handler will be too far away from the source
of the error to do any good.

> The way I look at things is that, each function/procedure/method is
> responsible for catching any expception it can generate. Then it either
> handle them locally, or if it can not, throw them to the caller.

In the Ariane 5 case, everyone was absolutely convinced that the line
in question could not generate an exception, and therefore they were
unprepared to handle it.

> At worst, a programmer can simply start their method with a try, and
> end it with a catch. 

In the Ariane 5 case, efficiency considerations dictated that unnecessary
tests could not be left in the code.

> Now, lets examine your statment again and show how illogical it is
> from a different point of view.
> 
> How is your statment different from:
> 
> 'But no one generally expects boundary array overrun exceptions, so no one
> writes exception handlers for them'.

It's not different.

> Are you then saying the language should NOT throw an exception when someone
> walks over the array boundaries travelling to lala land as they wish?

I'm saying that in the field, especially in software which must work the
first time, that such an exception will do more harm than good. It's quite
possible that code will produce the externally correct effect even after
it has stepped out of the bounds of an array. It's usually not possible
for code to produce the externally correct effect when it throws an
exception.

Such exceptions help the programmer during the test and debug phase of the
programming cycle. If the delivered code is not mission-critical, then it's
even OK to let the exceptions happen where the customers can see them, so
that they can report back unforseen problems. But when the code must do its
job correctly, always, even the first time, then overflow and bounds checking
should be turned off in the field, because that way, it's more likely that
the program will be able to complete its job.