🚀 go-pugleaf

In article <1992Sep29.201603.19289@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
>The more I think about it, the more I'm convinced that the uses for
>exception specifications are astonishingly restricted.  ...
...
>All of which leads me to believe that exception specifications are not
>really designed for the "general use" suggested in the last paragraph of
>commentary in ARM 15.5c.  That being the case, I'm tempted to suggest they
>be removed from the language.

I'd suggest studying the exception specifications in Modula-3 (latest
version).  Those are based on years of experience with Cedar and
Modula-2+, as well as a study of the effects of changing the exception
specification rules a large body of software already written in
Modula-2+.  Modula-3 has "object methods" that are more or less
equivalent to C++ "virtual member functions", so the rebinding problem
does not go away.

As I recall, the M-3 rules are:

   no specification is equivalent to "no exceptions raised".

   the set of exceptions raised is part of a function type.

   assignment to function variables and/or binding to object methods
   must be type correct (i.e., in V := F, the set of exceptions raised
   by F must be a subset of the exceptions raised by V -- this is
   checked statically).

   if a function F calls a function G, static checking may provide
   a warning if G can raise an exception not in the list of exceptions
   raised by F.  If this happens at run-time, the exception is
   converted to a "failure exception" that can only be caught by
        TRY ... EXCEPT ... ELSE <catch it here> END
   though finalization clauses will be executed.

I do not know how this corresponds to the exception specifications for
C++; I only know that these are sane and that they work.  The use of
objects types as exception types (as in C++) appears to be compatible
with this, and an improvement (at least in the case of single
inheritance).

David Chase
Sun