Re: Why no Propagates?

["Norman H. Cohen" <ncohen@watson.ibm.com>]

Matthew Heaney wrote:

> In article <326391B6.4B23@gsfc.nasa.gov>, Mike Stark
> <michael.e.stark@gsfc.nasa.gov> 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