Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!quintus!ok From: ok@quintus.uucp (Richard A. O'Keefe) Newsgroups: comp.lang.fortran Subject: Exception handling (was Fortran vs C for computations) Message-ID: <401@quintus.UUCP> Date: 14 Sep 88 08:22:35 GMT References: <390@quintus.UUCP> <3501@lanl.gov> Sender: news@quintus.UUCP Reply-To: ok@quintus.UUCP (Richard A. O'Keefe) Organization: Quintus Computer Systems, Inc. Lines: 177 Meta-comments: (1) I have posted a message to comp.arch asking which machines cannot support a simple exception-handling system. If anyone reading this newsgroup has this information, let's have it. Does anyone have any hard data on how much an exception-handling system slows things down? (2) This has degenerated into an argument between me and Giles. I am proposing that Fortran should have some sort of exception handling facility as part of the standard, which facility would not require the existence of precise interrupts. Indeed, the only actual run-time support required is a branch to the part of the user's code which says what to do if the exception in question cannot be trapped. Giles claims that this would be an intolerable burden on people who are trying to get maximum performance from their systems, that it is inflexible, that "correct" programs don't need any such thing, and that an exception-handling facility if it exists at all should be "language-independent" (though this does not mean that it should work with every current language). I really don't think that either of us is likely to change our mind. Certainly not if we are the only ones discussing the topic. Part of the problem is that I don't know what it is like to use a Cray or any other super-computer. What we need, if this discussion is to actually be *useful*, is input from other people. Does anyone other than Giles understand why he finds my suggestion objectionable? For the purpose of discussion, let's make my proposal concrete: 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. 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? This scheme was designed to be compatible with ADA, or with PL/I, or with the only Common Lisp error handling proposal I know anything about, or with UNIX C. Is anyone mixing Fortran with some other language having an exception handling facility that this is not compatible with? Because I don't think the discussion is getting anywhere, I shall only post on it again if someone else enters the discussion. In article <3501@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <390@quintus.UUCP>, by ok@quintus.uucp (Richard A. O'Keefe): >> - the possibility of the program *substituting* a *different* >> calculation in place of the faulted one. (Think "recovery >> blocks".) > >This assumes that the original code (which generated the fault) hasn't >changed the data while it was executing. NO IT FLAMING WELL DOESN'T! It assumes that if you want to try to substitute a different calculation, you have saved a copy of the things which might change. I was going to say in one of my messages that a compiler would assume that everything which *might* have changed in a protected region was to be treated as trashed, but I decided that that was so obvious it didn't need to be said. Oh well. >Most real applications don't have that kind of memory. I might have the data on disk. Or the data which are changed might be just a few bytes. (And yes, I do know what recovery blocks are. Surely it was obvious that I meant "Think in terms of code which is _like_ recovery blocks explicitly programmed by the programmer"?) >Deleting scratch files (and other such destructive habits) are _VERY_ >bad ideas. The cause of the exception might be contained in that scratch >file. I guess Giles has never been on a machine which ran out of disc space because a buggy compiler didn't clean up its scratch files. I do not say that a program should *ALWAYS* delete scratch files (though it is UNIX practice to regard doing so as elementary good manners). What I say is that the programmer should have the CHOICE. >By deleting it, you have destroyed valuable evidence to the >user in finding the cause of the fault. Note the assumption that the >>user<< is responsible for debugging the program. >Since this is a C VS. Fortran discussion, I guess that you're saying >C doesn't have this fault. No, this is >not< a C -vs- Fortran discussion. At least not on my side. Error handling in C is pretty appalling. Didn't I already mention that there is _no_ guaranteed way in C of obtaining the error code from a library function? >> Let's see what assumptions we can find in it. >> (3) There are non-trivial correct programs. >I don't know what this means. Giles said that exception handling should not be required because it would slow down correct programs. I claim that there are precious few correct programs to worry about. >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. I did not imply that. Fortran already has GOTO and alternate RETURN; it doesn't need another control structure just for jumping around. Far from saying that such a program was 'correct', I was denying that there *are* (m)any 'correct' programs. >Reliable systems are ones which don't produce _wrong_ answers. Agreed. (And having apparently created an output file very often amounts to producing just such a wrong answer.) >You are the one that is claiming that only one type of person matters: >those who crave your brand of robustness. No. I have proposed an exception handling scheme which has *ZERO* overhead if it is not used. >> I also point out once more that my proposal would allow an implementation >> to say "no, I can't do this", which means that it would have *ZERO* >> performance impact when a program did not request exception handling. > >No, your proposal would allow the language designers to say what _they_ >wanted the implementation to do. If _they_ say that the option "no, >I can't do this" is illegal in their language, then that's that! But my proposal explicitly said that saying "no I can't do this" SHOULD be legal. >>>A language-independent library standard could be developed to address these >>>points. >> >> Let's see it! Don't forget, there's ADA, APL, BASIC, C++, COBOL, FORTRAN, >> LISP, ML, MODULA-2, PASCAL, PL/I, SIMULA, Smalltalk-80, ... > >I said 'language-independent' not 'universal'. I didn't say universal either. I only listed languages which I know can run on a VAX. Which languages _should_ a library standard be dependent on in order to qualify as "language-independent"? >That doesn't make it a good idea!! By your logic, language designers >should never even _try_ to learn from the mistakes of others. I don't see how he draws this conclusion. One of the key mistakes is leaving something out. I/O was left out of Algol 60, and where is it today? >> There are at least two kinds of programs: >> (s) programs for wizards (yourself, other people in your group, certainly >> noone who lacks access to the source code or wouldn't understand it). >> (o) programs for mortals (especially programs written for sale to people >> who do not get the source code). >> I get the impression that Giles is thinking in terms of (s), while I am >> thinking in terms of (o). [...] > >No, I'm thinking in terms of _BOTH_. I know, flexibility is a novel >idea. YOU'RE the one who claims that language standards should exclude >one of these two groups. But my proposal has ZERO run-time cost if it is not used. How on earth does that exclude the wizards? How is having an extra standard feature available which you don't have to use inflexible?