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 Subject: Re: Ada and Java. different behaviour. casting long to int problem. Date: 1999/06/18 Message-ID: #1/1 X-Deja-AN: 491233288 Sender: hymie@calumny.jyacc.com References: <7jt2c0$vrb@drn.newsguy.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> <3769506F.157411C0@mitre.org> <7kbujm$1kb@drn.newsguy.com> <7ke2dg$2a7a@drn.newsguy.com> Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@panix.com X-Trace: news.panix.com 929744796 16827 209.49.126.226 (18 Jun 1999 22:26:36 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 22:26:36 GMT Newsgroups: comp.lang.ada Date: 1999-06-18T22:26:36+00:00 List-Id: mike@ooo.nospam.com writes: > In article , 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.