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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1094ba,86e8c626be2471ae X-Google-Attributes: gid1094ba,public X-Google-Thread: 103376,fc050a66c3b5d87d X-Google-Attributes: gid103376,public From: "James Giles" Subject: Re: F9X twister & ADA (was: n-dim'l vectors) Date: 2000/04/12 Message-ID: #1/1 X-Deja-AN: 610293324 References: <8cctts$ujr$1@nnrp1.deja.com> <38EA0440.1ECBC158@ncep.noaa.gov> <38ED4ECA.ADB698C9@sdynamix.com> <38F28A85.53809F39@sdynamix.com> <38F2C1DC.5538F9F0@research.canon.com.au> <5jJI4.297$PV.9915@bgtnsc06-news.ops.worldnet.att.net> <38F3D1D3.416B3493@research.canon.com.au> <85SI4.4008$fV.338113@bgtnsc05-news.ops.worldnet.att.net> <38F3F803.A4A56259@research.canon.com.au> <38F41313.DAF90E74@research.canon.com.au> <38F492A7.997140CF@quadruscorp.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc06-news.ops.worldnet.att.net 955560787 12.74.2.32 (Wed, 12 Apr 2000 17:33:07 GMT) Organization: AT&T Worldnet NNTP-Posting-Date: Wed, 12 Apr 2000 17:33:07 GMT Newsgroups: comp.lang.fortran,comp.lang.ada Date: 2000-04-12T00:00:00+00:00 List-Id: Marin D. Condic wrote in message <38F492A7.997140CF@quadruscorp.com>... >Geoff Bull wrote: >> > I still prefer to quit *immediately*. >> You missed my point. >> Depending on the situation different users will have different needs. >> Quit immediately simply isn't appropriate in may situations, >> even if it happens to be perfect for you. >> >I'm with you. Core dumps and such are interesting when you are in >program development mode and you need information about where something >terminated, etc. But in production mode, core dumps are at minimum >impolite. [...] Gee, I guess you missed earlier in this thread when I said: >In any case, for most of my own code I much prefer halting >immediately. Most "graceful" termination involves doing >things that cover up evidence that might be needed to discover >the cause of the fault (closing files, deleting temporaries, leaving >the program counter and/or the registers in different states than >the context in which the error arose, etc.). It's only for code >written for naive public consumption that "graceful" termination >is appropriate. And yes, in this case a clear message is >important. Any code I write myself (or any "in-house" code) is in the presence of the developer(s). If there's an error, the proper course of action to take depends on who's running the program. If it's my own code, the proper action is to preserve as much information about the failure as possible - in order that I can fix it. I'm sorry if you missed the fact that there are two aspects of this thread. First, there is the claim that it's *never* desirable to halt immediately, that I disagree with. Second, there is the claim that, when you *are* going to catch the error and "gracefully" terminate, having the raised exception be handled by a non-specified (and often completely surprised) exception handler is desirable. "Completely surprised" did I say? Yes. In the earlier example, suppose procedure Z raises an exception that A has an active handler for. The author of A as I specified, is a different person than the author of Z. In fact the author of A is using a library written by some third party who wrote neither A nor Z. Z is only present at the end of a long dependency chain through several libraries written by different people. If the author of A wrote a handler for a given exception, it was almost certainly to handle a problem that he knew might arise *in* A. The message written by the handler (or other remedial action) will be written under the assumption that the cause of the exception was the expected possibility within A. Later, when debugging the problem, the author of A will be completely surprised that the exception came, in this case, from Z (a procedure which the author of A had no prior knowledge of at all). -- J. Giles