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: 103376,fc050a66c3b5d87d X-Google-Attributes: gid103376,public X-Google-Thread: 1094ba,86e8c626be2471ae X-Google-Attributes: gid1094ba,public From: "James Giles" Subject: Re: F9X twister & ADA (was: n-dim'l vectors) Date: 2000/04/12 Message-ID: <85SI4.4008$fV.338113@bgtnsc05-news.ops.worldnet.att.net>#1/1 X-Deja-AN: 609939225 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> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 955510212 12.74.2.44 (Wed, 12 Apr 2000 03:30:12 GMT) Organization: AT&T Worldnet NNTP-Posting-Date: Wed, 12 Apr 2000 03:30:12 GMT Newsgroups: comp.lang.fortran,comp.lang.ada Date: 2000-04-12T00:00:00+00:00 List-Id: Geoff Bull wrote in message <38F3D1D3.416B3493@research.canon.com.au>... ... > Handling may be as simple as: > when others => Put_line ("Internal error: contact vendor); > >which to me is a lot better than the program simply halting in the >middle of nowhere. I can't see the advantage of halting immediately, >if you want to halt just don't provided exception handlers. If you can control that. The procedures in Ada neither declare which exceptions they might raise, nor have any other indications that an exception might arise. How do you *not* provide a handler when you don't even know what it is that you're trying not to handle? 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. >> Mystically skipping over several >> levels of the call tree is messy. > >I don't understand what you mean here. I can't see any opportunity for confusion here. A procedure raises an exception and some remote ancestor process catches it. Say, A calls B, B calls C (which is in a separately designed library), C calls D, etc. through the whole alphabet and several distinct, separately designed libraries. When Z raises an exception, A may have a handler active for it. The programmer who wrote A probably isn't even aware that procedure Z exists, much less is (s)he prepared to handle an error that arose there. Now, a signal (as distinct from an exception) might be proper here. But signals are generally for external things (like: your asynch I/O is done) or for non-specific, but fatal things (like KILL). If Z wants to send a KILL signal and procedure A has set up a handler for that signal (to do "graceful" termination, for example), that's fine. You're not pretending to be able to handle a given specific error. And you'll respond identically whether the signal was internally generated or sent from the system or the program's user. The whole idea of libraries (and most modular programming) is for different programmers and teams *not* to have to know the internals of the work of others. Yet, raised exceptions propagate across such boundaries in an undeclared and, usually undocumented way. At the very least, the programmer should never allow an exception to leave the confines of the package in which it is raised (which may consist of many levels of procedures to be sure) without explicitly declaring to the users of the package which public procedures may raise an exception that the package itself doesn't handle. What exceptions each of these may raise should also be explicitly declared. Yes, this means that when you add code which may raise exceptions to a procedure, you have to recompile (and maybe even rewrite) code which uses that procedure. This is no different than any other case in which you changed a procedure in a way in which its public (interface) properties have changed. Or, are you claiming that an exception is not a public property of the procedure which raises it? Ideally, the language design itself should enforce this rule. It's certainly the kind of thing that should be considered when designing an exception handling mechanism for a language which doesn't yet possess one. One of the nice things about discussions of this type is that it forces the re-evaluation of previous ideas in new light. About three years ago I posted a suggestion for Fortran exception handling (which was criticized and/or ignored). Already, from this thread I see several things I'd now suggest be done differently. But I still wouldn't recommend Ada as an ideal model. -- J. Giles