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,799e6e37c90ca633 X-Google-Attributes: gid103376,public From: Martin Dowie Subject: Re: Future Ada language revisions? Date: 1998/10/06 Message-ID: #1/1 X-Deja-AN: 398322928 X-NNTP-Posting-Host: dowie-cs.demon.co.uk:193.237.34.207 References: <6um7on$db5$1@nnrp1.dejanews.com> <6v9es0$bnv$1@nnrp1.dejanews.com> <6vdbcg$p9c$1@nnrp1.dejanews.com> X-Complaints-To: abuse@demon.net X-Trace: news.demon.co.uk 907693461 nnrp-05:10946 NO-IDENT dowie-cs.demon.co.uk:193.237.34.207 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-10-06T00:00:00+00:00 List-Id: In article <6vdbcg$p9c$1@nnrp1.dejanews.com>, dennison@telepath.com writes >What about exceptions raised by a called subprogram *called by* this >function? what indeed! if handled internal, no problem. if out of scope perhaps the 'new spec' could be extended with something like an 'or others' statement to indicate that an anonymous exception is possible. > How about those that are raised within a rendezvous? a case for expanding the 'entry' specification too? > What if said >exception isn't visible in the package specification where this declaration >has to be placed? see point 1 > How is the compiler to know that I even *want* an exception >handled? perhaps 'pragma surpress' or a compiler option could indicate that this warning should not be given? > Do you want every unit that calls Put_Line to spit out warnings >about missing explicit handlers for use_error and mode_error? if the 'or others' extension is provided then it wouldn't. if this option was missing then your spec or body wouldn't be concidered complete as either a) the spec does cater for the those errors; or b) the subprogram body didn't handle them in some way. eithe way the exceptions you can currently get would still occur at exactly the same time as they do now, but the compiler would be able to provide a stronger check. so the general feeling seems to be that when deciding to handle exceptional cases and to search out which subprograms raise which exceptions, perhaps after the body has changed, or, if any are raised at all, is best left to the programmer to do by hand (or buying another tool to do this) rather than getting the compiler to do it as part of the language. could someone please point me in the direction of a tool that actually does this?!?! i certainly don't have the time to sit an write one myself! the other down side to me is in legacy code, which unless this sort of thing were optional (rather defeating the purpose) would have to be revisited and updated. still who knows what you might find then... -- Martin Dowie