Path: utzoo!attcan!uunet!husc6!ukma!uflorida!novavax!hcx1!hcx2!bill From: bill@hcx2.SSD.HARRIS.COM Newsgroups: comp.lang.fortran Subject: Re: Exception handling (was Fortran vs Message-ID: <44400022@hcx2> Date: 16 Sep 88 14:40:00 GMT References: <401@quintus.UUCP> Lines: 53 Nf-ID: #R:quintus.UUCP:401:hcx2:44400022:000:2530 Nf-From: hcx2.SSD.HARRIS.COM!bill Sep 16 10:40:00 1988 Only fools rush in... I will probably regret jumping into this discussion; for the record, I don't intend to respond further unless some other interesting point(s) is raised. I merely want to answer some questions and misconceptions (I think). Background: I work for Harris Computer Systems, maintaining compilers; I helped develop our Ada compiler and continue to be involved in its maintenance. > HANDLE ('exception name, ..., exception name') IN > statements to be protected > CANNOT HANDLE > statements to execute if any of the exceptions cannot be trapped > HANDLER > statements to execute if any of the exceptions occurs > END HANDLER > The compiler is to assume in the HANDLER branch that any variable > which might be altered by the protected code has been trashed. > The list of exception names is a CHARACTER*(*) expression. A compiler > would be entitled to generate code for *just* the CANNOT HANDLE branch, > though it would be good manners to print a warning message. The > precise location of an exception does not matter, but any pending > exceptions must be signalled before control leaves the protected code. Oh, but it does. Without a precise location, how can the generated code (or the runtime, or whoever) figure out whether the exception occurred _inside_ the HANDLE section or _outside_. This single fact causes us headaches in Ada, because it is VERY expensive on our hardware to determine exactly where the exception occurred. (I believe this is almost universally true in cases where floating-point operations are done by an independent co-processor.) > On which machines must this be inefficient (but how _can_ just > compiling the CANNOT HANDLE branch be inefficient?) and what are the > reasons for this inefficiency? Again, in order to know that the CANNOT HANDLE branch should be executed requires knowing where the exception occurred. >>If you're implying that a code which >>deliberately generates (and recovers from) an exceptional condition >>is 'correct', you have a strange concept of what correctness is. This is quite common (I am told by Ada users). The most common situation is doing some calculation on data obtained from some real-time measuring device; overflow is possible, but the desired result is just "the maximum value". In Ada, this is easy: trap the overflow exception and substitute the desired value. Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or bill%ssd.harris.com@eddie.mit.edu