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=0.2 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY,XPRIO_SHORT_SUBJ autolearn=no 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 09:16:15 PST Path: supernews.google.com!sn-xit-03!supernews.com!freenix!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: RISC Date: Mon, 19 Mar 2001 12:02:59 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <995e4m$n90$1@nh.pace.co.uk> References: <98tt7g$88h$1@nh.pace.co.uk> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 985021398 23840 136.170.200.133 (19 Mar 2001 17:03:18 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 19 Mar 2001 17:03:18 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: supernews.google.com comp.lang.ada:5853 Date: 2001-03-19T17:03:18+00:00 List-Id: It isn't an efficiency issue. Its more of a "design philosophy" issue. If you are working with systems that have a really high reliability requirement, you'll get various arguments for and against using exceptions. (Hard to mathematically "prove" the code, vs "that's what exceptions are for!" arguments.) Exceptions can be viewed as a sort of "limited/controlled goto" - and as such they can pose hazards to good software design. For example, the Text_IO package will raise an exception if you try to read past the end of a file because it has no way of knowing what you are attempting to do or why. It just knows you asked it to do the impossible so it properly throws up its hands, curses you in exasperation and raises an exception. However, *your* code ought to know what it is doing with the file and should properly be checking for End_Of_File as an anticipated condition. You might protect yourself by trapping any EOF exceptions because you may have made a programming error and in some corner case you attempt to read past the end of the file. Your code should be raising exceptions in similar circumstances - when it becomes clear that some condition has occurred that is beyond the understanding and the *responsibility* of the module in which it is raised. A good example is a function that is undefined for some combination of parameters. The function in effect says "I have no idea why you sent me this combination of numbers and there really isn't anyting intelligent I can do with them to fix the problem and let you press on, so I'm going to raise an exception that you cannot ignore so you are aware that you probably made a mistake." The calling code should be trapping exceptions (or not) as a means of catching unexpected conditions - but not as a normal transfer of control mechanism. (You would consider it "bad form" to terminate your programs by dividing by zero, wouldn't you? Same concept here.) And remember that raising & handling exceptions may or may not be done depending on the nature of the system. You have to consider this in the requirements/design phases of the system & plan accordingly. (id est, take a decision about what exception philosophy should be followed for *this* application.) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Charles Hixson" wrote in message news:vIYs6.6150$227.669029@newsread2.prod.itd.earthlink.net... > 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? > > 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. > > 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. > > 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. And that they should be handled as close to > the routine that raised them as possible. Preferably within the routine. > But I would hardly call myself an expert at Ada. > >