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: Robert A Duff Subject: Re: Ada and Java. different behaviour. casting long to int problem. Date: 1999/06/24 Message-ID: #1/1 X-Deja-AN: 493387727 Sender: bobduff@world.std.com (Robert A Duff) 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> <7kaa6o$nr3$2@wanadoo.fr> <376906CF.109EEF55@pwfl.com> <7kbaoc$1588@news2.newsguy.com> <3769519B.9B0F880@pwfl.com> <3770F360.37A5B472@pwfl.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-06-24T00:00:00+00:00 List-Id: Marin David Condic writes: > Keith Thompson wrote: > > I've always found this wording a bit odd. The way Operand Error is > > capitalized implies that it's a technical term, but course there's no > > predefined Ada exception by that name. Presumably they're referring > > to Constraint_Error (or possibly Numeric_Error if they were using an > > Ada 83 compiler). Perhaps "Operand Error" is the name of a > > hardware-level error condition? > > > As I've said elsewhere, my recollection was that the system ended up > going to an interrupt handler and, as you observe, there is no such > thing in Ada (that I'm aware of) called Operand_Error. On the 1750a, > there is a fixed point overflow interrupt and several user definable > interrupts which may have somehow ended up tagged with this terminology. It's not clear what sort of "data conversion" they're talking about in the report. Is it an Ada type_conversion, as in "Integer(Some_Float)"? Or is it a subroutine that's doing something similar -- that could explain the "Operand Error" -- maybe the subroutine raises that exception. > It is possible that they meant having a "begin exception end" block > around the computation, but you don't usually see people doing that. > There's usually an exception handler at the end which catches all the > errors. And since the handler in and of itself is not (usually) run-time > intrusive, there would be no reason to remove the handler in the > interest of efficiency. Unless they were worried about space efficiency. It does seem strange that they would eliminate the exception handler, but not eliminate the code that raises the exception, if they were that worried about efficiency. Which makes me think that it must have been a hardware-detected exception. But that would raise Constraint_Error, not some user-defined thing called "Operand_Error". Strange. - Bob -- Change robert to bob to get my real email address. Sorry.