Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!hc!lanl!jlg From: jlg@lanl.gov (Jim Giles) Newsgroups: comp.lang.fortran Subject: Re: Exception handling (was Fortran vs C for computations) Message-ID: <3576@lanl.gov> Date: 14 Sep 88 20:53:19 GMT References: <401@quintus.UUCP> Organization: Los Alamos National Laboratory Lines: 115 From article <401@quintus.UUCP>, by ok@quintus.uucp (Richard A. O'Keefe): > [...] > 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 I object to your implication that a proposal to a language standard committee will emerge intact. The CANNOT HANDLE statement would almost certainly _not_ make it. Your whole argument hinges on the claim that CANNOT HANDLE will be a feature of the language. It's not in any other languages I'm aware of. >>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! [...] Yes it does! It assumes that the data was not changed by the original code. You claiming that you _implied_ the same thing was not true, nor does it make my statement false. Saving data around suspect code is an expensive way of meeting the assumption. >>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. Oh, fine! Now all code which _might_ generate exceptions has to do disk I/O to preserve the data. _THAT_ won't have a performance penalty? > 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. Exactly, The _programmer_ should choose. Not the _program_, the _programmer_. Only the person who does the debugging can decide which data will be necessary to figuring out the cause of the fault. And yes, I have been on machines which ran out of disk space. On at least one occasion the cause of the run-away disk grabbing was found in one of those temporary files that you want to automatically delete. >>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. The user is the one responsible for debugging. If he doesn't do it himself, he must find someone who will (or give up). If the user or the program destroy the data necessary for debugging to be successful, then NOBODY will do the debugging. At this point in such discussions, the argument is usually raised that one could re-run the code from scratch and debug it interactively - thereby eliminating the need for keeping the whole context the first time the code failed. This assumes that re-running from scratch is a cost effective thing to do. A production code which fails after 100+ hours of Cray time is _not_ a candidate for this kind of debugging. I've had this argument about auto-destruct temporary files before - usually a few hours in the consulting office watching real user problems being solved will cure anbody who thinks it's a good idea. > No, this is >not< a C -vs- Fortran discussion. At least not on my side. Gee, the subject line said: ... Fortran vs. C ... in it until your last message. I guess I maid too much of an assumption that the subject line had something to do with the articles. >>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"? It is desireable for all the languages in a given programming environment to be call-compatible (procedures in each language capable to call procedures in some other language). My proposal would provide for a _single_ library of exception handling routines for all languages which are call-compatible. My proposal would provide for a _single_ library specification for all languages which contain the concept of procedure calls - whether they are call-compatible or not. > 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? Just because _I_ don't _have_ to use a feature, doesn't make it harmless. Any feature in the standard _has_ to be implemented in order that the environment be standard conforming. As an implementor, I can tell you that features have effects on each other. Even a rarely used feature may have a profound effect on more commonly used ones. Suppose that your 'ZERO cost' option doesn't make it into the standard (like ADA). Suppose instead that some option like ON OVERFLOW SET RESULT TO BLIVET (where BLIVET is some predefined constant) is added? I've talked to hardware designers in Cray and IBM - such a feature is _VERY_ expensive (at least for vector and/or pipelined hardware). Your proposed solution has (at least) three problems: 1) it requires the cooperation of the language standards committees (at times these people can be _very_ intractable). 2) it _doesn't_ promote and increased compatibility _between_ languages. 3) because of 1) and 2), your proposal would require as many different implementations of the _same_ functionality as there are languages. J. Giles Los Alamos