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/05 Message-ID: #1/1 X-Deja-AN: 398052080 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> <3619254C.C82A4A71@icon.fi> X-Complaints-To: abuse@demon.net X-Trace: news.demon.co.uk 907623229 nnrp-04:20711 NO-IDENT dowie-cs.demon.co.uk:193.237.34.207 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-10-05T00:00:00+00:00 List-Id: In article <3619254C.C82A4A71@icon.fi>, Niklas Holsti writes [snip] >I'd prefer to leave the analysis of exception flow to a static analysis >tool, and not require a list of possible exceptions in the spec, at >least >not a complete list. do you know of any tool that currently does this? i haven't come across one yet (the nearest similar listing would be unused data objects/subprograms that a linker has removed). >Consider the case where you have a deeply layered program, with MAIN >calling module A calling module B calling ... calling some library L. >If an exception raising is added to L, intended to signal a fatal >error to MAIN, you would have to modify the specs of all intermediate >levels. Then, what if some intermediate level modules are also used >in some other project, with a different library L, which does not raise >this particular exception? Requiring a list of all possible exceptions >on all levels would make code sharing harder. fair point - but even without this extension, the behaviour of a different library unit would (should) be concidered for differences which might also require changes to the mid-level units. also hasn't the behaviour of the mid level units changed if using this lower level unit (it no longer raises the exception)? shouldn't this change in 'exported' behaviour be explicit in its specification? this would force the user of the mid-level package to reconcider his decisions. >I could accept having the list optional. Perhaps it would be good >to allow "others" as the last element in the list, to mean that the >list is possibly incomplete: > > function Blah return Boolean > or Some_Exception or others; > >(I'd prefer a syntax that places "or" between all exception names, >instead of separating them with commas. Also, the "exception" is >unnecessary and it doesn't add a whole lot of readability, since >most exception names already hint at exceptions, for example >"Constraint_Error".) >One trouble spot could be exceptions raised by run-time checks that >may or may not be elided, depending on the compiler. For example, >a smart compiler given a strongly typed subprogram might >elide all constraint checks, and therefore the subprogram should >not be specified as possibly raising Constraint_Error -- or should it? >Another, dumber compiler perhaps could not prove to its own >satisfaction that Constraint_Error is impossible, and so would >complain about the missing "or Constraint_Error" in the spec. a case for having these as compilation warning rather than errors? 'others' could also still cater for anonymous exceptions. all i'm really trying to point out is that subprogram specifications appear to be "incomplete". ada seems to go out its way to allow as many compile time checks as possible with specifications allowing 'contracts' to be made between provider and user - except in this one area. -- Martin Dowie