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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,fee8802cc3d8334d
X-Google-Attributes: gid103376,public
From: Hyman Rosen <hymie@prolifics.com>
Subject: Re: Ada and Java. different behaviour. casting long to int problem.
Date: 1999/06/18
Message-ID: <t71zf9cwuy.fsf@calumny.jyacc.com>#1/1
X-Deja-AN: 491108201
Sender: hymie@calumny.jyacc.com
References: <7jt2c0$vrb@drn.newsguy.com> <f92d7yyweva.fsf@eng.sun.com>
 <7k57vb$1ipf@drn.newsguy.com> <3766650F.705125B7@pwfl.com>
 <7k64t7$igo$1@its.hooked.net> <7k689a$ci2@drn.newsguy.com>
 <3766C842.E1EAB60A@pwfl.com> <3766D1CC.D712895E@itools.symantec.com>
 <7k8nn5$qcb$1@its.hooked.net> <3767E8A2.EF1A0570@itools.symantec.com>
 <7k8tv3$3gm@drn.newsguy.com> <t7so7rdd1u.fsf@calumny.jyacc.com>
 <3769506F.157411C0@mitre.org> <t7bteed21s.fsf@calumny.jyacc.com>
 <7kbujm$1kb@drn.newsguy.com>
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: abuse@panix.com
X-Trace: news.panix.com 929722146 11503 209.49.126.226 (18 Jun 1999 16:09:06
 GMT)
Organization: PANIX Public Access Internet and UNIX, NYC
Mime-Version: 1.0
User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) Emacs/20.3
NNTP-Posting-Date: 18 Jun 1999 16:09:06 GMT
Newsgroups: comp.lang.ada
Date: 1999-06-18T16:09:06+00:00
List-Id: <comp.lang.ada>

bob@nospam.com writes:
> This logic does not make sense at all.
> 
> When an exception happen, you catch it, and then you can simply
> ignore it if that is really what you want to do depending on the
> exception, or you print some error message and also ignore it,
> or you can throw it again.  The point is, raising an exception and 
> handling it, are 2 different issues. So your point about the program 
> abruptly aborting do not make sense.

But no one generally expects arithmetic overflow exceptions, so no one
writes exception handlers for them. In the Ariane 5 case, the very line
that caused the exception was carefully examined by the designers, who
concluded that there could be no overflow, and that therefore no check
was needed.

As a result, when an overflow exception happens, there is no local
handler to process it. The exception propogates outward, destroying
subroutines in its path, until some outermost catch-all handler
finally triggers, or the program aborts. The result, to the user of
the code, can be much worse than continuing to process with bad data.