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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,78b2880bc7e78e39 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-19 07:44:09 PST Newsgroups: comp.lang.ada Path: supernews.google.com!sn-xit-03!supernews.com!logbridge.uoregon.edu!netnews.com!feed2.onemain.com!feed1.onemain.com!uunet!dca.uu.net!ash.uu.net!world!bobduff From: Robert A Duff Subject: Re: RISC Sender: bobduff@world.std.com (Robert A Duff) Message-ID: Date: Mon, 19 Mar 2001 15:42:19 GMT References: <98tt7g$88h$1@nh.pace.co.uk> Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.3/Emacs 19.34 Xref: supernews.google.com comp.lang.ada:5844 Date: 2001-03-19T15:42:19+00:00 List-Id: Charles Hixson writes: > Robert A Duff wrote: > > > "Marin David Condic" writes: > > > >> Its hard to come up with absolute rules since it often requires > >> subjective, artistic judgements. Just keep in mind that the intention is > >> to have a mechanism that deals with *errors* - not anticipated conditions > >> that can be accommodated with some sort of "normal" processing. > > > >.... > > Another way to look at it is that the point of exceptions is to separate > > the code that *detects* errors from the code that *handles* those > > situations. If the code that detects something knows what to do about > > it, then exceptions aren't necessary -- that code can just have an 'if' > > statement that checks the condition, and handles the situation in the > > 'then' part. > > > > - Bob > > Is the problem that exceptions are expensive, or that exceptions violate > localization? Or something else? I'm not sure which problem you're referring to. I was just trying to explain the point of exceptions (ie, why do we have exceptions instead of just if statements and whatnot). I wasn't trying to point out any problem. > E.g.: Should EOF detection be done with an exception? It's usuaual, but > expected. I think of encountering an EOF and an unusual condition, and > it's nice to be able to automatically check for it whenever a read happens > without explicitly calling on an eof() function. I prefer the function in the EOF case. > Java rather expects that procedures will throw exceptions. I don't know > C++ well enough to comment. Python seems to believe that exceptions are > quite reasonable. Eiffel thinks that exceptions should be handled within > the same routine that defines them. Etc. I think that this is a language > specific issue. True. But as a language designer by nature, I tend to think about "how should I design an exception facility", rather than just, "how should exceptions be used in this particular language", given the biases of the language designer. > My impression was that Ada exceptions were intended to handle unusual cases > (exceptional cases). That they were slightly more expensive to raise than > a local branch would be, but that they were slightly cheaper if no > exceptional case was detected. Sort of true, except for the "slightly" part. In a good Ada implementation, it is enormously more expensive to raise an exception than to do an if_statement or whatever. Perhaps 1,000 times more expensive (just a wild guess). If the exceptional case is *not* detected, you still have to execute the compare instruction (or whatever) that would have detected it, so I see no difference there (unless you're talking about something like overflow, which can be detected by the hardware "for free" on some machines). This efficiency trade-off is because of the intended use of exceptions, not the other way around. >... And that they should be handled as close to > the routine that raised them as possible. Preferably within the routine. I don't agree. If it's handled in the routine itself, why raise and handle an exception? Why not just write: if X.Length < 1 then Do_Something_About_It; Exceptions are for the case where the "if X.Length < 1 then" is in a different procedure than the "Do_Something_About_It;", because the procedure that detects the error doesn't *know* what to do about it. I'm not talking about efficiency here -- it would be possible to implement very-local handlers as efficiently as an if statement / conditional jump. But nobody does that, because it's not the way exceptions should be used. The "as close to" part of what you wrote is often true. But there are certainly cases of handling exceptions very far away: the main program might handle "others", and then crash gracefully -- it has no idea where the exception came from. - Bob