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,a3ca574fc2007430 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Ada and Automotive Industry Date: 1996/12/18 Message-ID: #1/1 X-Deja-AN: 204824128 references: organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-12-18T00:00:00+00:00 List-Id: In article , Robert Dewar 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