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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3ccb707f4c91a5f2 X-Google-Attributes: gid103376,public From: "Norman H. Cohen" Subject: Re: Why no Propagates? Date: 1996/10/18 Message-ID: <326798F6.2C52@watson.ibm.com> X-Deja-AN: 190323256 references: <325D7F9B.2A8B@gte.net> <326391B6.4B23@gsfc.nasa.gov> content-type: text/plain; charset=us-ascii organization: IBM Thomas J. Watson Research Center mime-version: 1.0 reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.ada x-mailer: Mozilla 3.0 (Win95; I) Date: 1996-10-18T00:00:00+00:00 List-Id: Matthew Heaney wrote: > In article <326391B6.4B23@gsfc.nasa.gov>, Mike Stark > wrote: > > >To which I would add further the fact that Java requires all > >user-defined > >exceptions raised by a method to be defined as part of the interface > >and caught by the client invoking the method (the "throws" keyword as > >used in specifying member functions). Ada does not make the list of > >exceptions raised by a subprogram part of the signature, let alone > >requiring user-defined exceptions to be handled by the caller. ... > > The designers of Ada 83 considered including explicitly naming the > exceptions propagated by a subprogram: > > procedure P (X : Integer) propagates A, B, C; > > This feature, and the reasons it was rejected, is discussed in section > 14.5.2 of the Ada 83 Rationale. > > The reason they did not include the propagates feature is because they felt > that it would add too much baggage ("code expansion") to subprograms, > especially to those that were otherwise small. A glance at the Ada-83 Rationale clarifies that the code expansion that concerned designers was object-code expansion, not the cluttering of source code. The alternative against which the Rationale argues presumes a run-time check that no exception other than A, B, or C (in the example above) is raised in P without being handled locally. This is quite different from the Java scheme (I hope that James Gosling will be less sensitive than Robert Dole to the use of the word "scheme"; his Java Language Specification coauthor Guy Steele is certainly in no position to object to it!), which is based on a compile-time check that any method call capable of raising an exception is either surrounded by a try block that handles that exception or enclosed in a method declared to throw that exception. (An exception to this rule is made for certain exceptional exceptions; see below.) A complication with applying such a compile-time rule in Ada is that an Ada exception can be propagated to places outside the scope of its declaration. If package P1 provides an exception E and a subprogram S1 that propagates E, and subprogram S2 (with a with clause for P1) calls P1.S1 but does not handle the possible raising of P1.E, then another subprogram S3 that calls S2 now requires a with clause not only for S2, but also for P1, so that P1.E can be named in either an exception handler or a "propagates" clause. It can be argued that this is not such a bad thing, especially if it imposes a discipline on the writer of S2 to handle the exception potentially raised by its call on P1.S1. It can also be argued that if the interface of S2 declares that it may propagate P1.E1, S2 ought to be enclosed in a package that also declares E: exception renames P1.E1; --thus obviating the need for a caller of S2 to have a with clause for P1. > Personally, I think it would be a cool feature to have. Let me the > programmer decide whether I want to incur the code-expansion penalty. (And > if the procedure tries to propagate something other than what's stated, > then raise Program_Error.) (Presumably, this rule would not apply to the exceptions declared in Standard, particularly to Program_Error itself! Note that this is the strawman run-time-check model of the Ada-83 Rationale, not the Java compile-time-check model.) Even though the Ada-83 Rationale was concerned with object-code bloat, source-code bloat is also a serious concern. Imagine having to explcitly address the fact that any call on any I/O subprogram might raise Device_Error! Every Ada program I've ever seen ignores this possibility, and manages to be just as useful and no less reliable. Indeed, Java applies its compile-time rule inconsistently to some, but not all, of the language-defined exceptions. All exceptions that are descendants of Error (essentially internal JVM implementation errors or malformed class files) and all exceptions that are descendants of RuntimeException (roughly the equivalent of Ada's Constraint_Error) are excluded. On the other hand, the rule does apply to all Java I/O exceptions, and this can be quite an annoyance. Sometimes I appreciate the discipline imposed by the Java rule, but often I find it a royal pain, forcing me to write try blocks for exceptions that can't be handled in any meaningful way anyway. Even the imposition of discipline depends on my good will: A naughty Java programmer can avoid the whole issue simply by adding throws Exception to every method declaration (or customizing his language-sensitive editor to it for him)! > To the designers of Ada 95: Was this feature considered for inclusion? Is > it a candidate for inclusion in Ada 0X? This feature did not come up during the Ada 9X revision process. So far, there is nobody vetting candidates for inclusion in Ada 0X. -- Norman H. Cohen mailto:ncohen@watson.ibm.com http://www.research.ibm.com/people/n/ncohen