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/11 Message-ID: <5jJI4.297$PV.9915@bgtnsc06-news.ops.worldnet.att.net>#1/1 X-Deja-AN: 609729483 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> 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 955474241 12.74.2.96 (Tue, 11 Apr 2000 17:30:41 GMT) Organization: AT&T Worldnet NNTP-Posting-Date: Tue, 11 Apr 2000 17:30:41 GMT Newsgroups: comp.lang.fortran,comp.lang.ada Date: 2000-04-11T00:00:00+00:00 List-Id: Geoff Bull wrote in message <38F2C1DC.5538F9F0@research.canon.com.au>... >James Giles wrote: >> Not that Ada is inherently superior. They >> did a lot of things badly too (their exception handling, for example). > >What don't you like about Ada exceptions? They may have fixed it by now (I haven't used Ada since the '80s). But, I haven't heard anything to suggest that exception handling was changed in the more recent standards. In Ada you can't tell what exceptions a procedure might generate from it's use or declaration. So your handler for a given block can't assume that the condition that arises is from the local code - if the block contains a procedure call. Exceptions arising from within procedures should be easily distinguishable from locally generated exceptions. A given exception might be actually handled by a remote ancestor in the call tree: which couldn't possibly have any specific knowledge about how to recover from an error so remote. At some point you should just turn such an exception into a non-specific "halt program" signal. Better: each procedure in the call tree should either explicitly handle exceptions or *explicitly* pass them to its (immediate) caller. If neither, the program should halt right there. Mystically skipping over several levels of the call tree is messy. Exception handling can be used as a form of Zahn's construct for *normal* flow control (not involving any error conditions at all). It is not very good programming practice, perhaps, but it can easily be done. If you intend to recover from them, handling hardware traps and faults (like float exceptions, or memory range errors) requires finer control than block-level structures. A single expression may have several operations that might cause such faults. If your exception handler is at the block-level, it needs to have an elaborate bit of code just to discover *which* possible cause actually triggered the exception. (I don't know an easy solution for this. But finer control is desirable for such cases.) Ada exception handling does too many things in one feature. Multilevel message passing (like C's setjump/longjump), one level error reporting (like Fortran's alternate return), local error recovery, and ordinary Zahn's-construct flow control. It would be better to have explicit control over each of these different uses. -- J. Giles