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: Niklas Holsti Subject: Re: Future Ada language revisions? Date: 1998/10/05 Message-ID: <3619254C.C82A4A71@icon.fi>#1/1 X-Deja-AN: 398032908 Content-Transfer-Encoding: 7bit References: <6um7on$db5$1@nnrp1.dejanews.com> <6v9es0$bnv$1@nnrp1.dejanews.com> Content-Type: text/plain; charset=us-ascii Organization: Space Systems Finland Ltd Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-10-05T00:00:00+00:00 List-Id: Martin Dowie wrote: [ snip ] > Would it be feasible to extend the specification for subprograms to > include a list of exceptions that can also be 'returned' from a > subprogram? here's an example using of what i'm driving at (hopefully > it's self explanatory) - > > function Blah return Boolean > or exception Some_Exception; > > and for multiple exceptions, something like - > > function Blah return Boolean > or exception Some_Exception, Another_Exception; 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. 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. 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. > Martin Dowie Niklas Holsti Space Systems Finland Ltd.