🚀 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.  As I see it, you
|> can't reliably put an exception specification on a function f if any of the
|> following are true:
|> 
|>     1.  A call to f might directly or indirectly lead to a call to g where
|>         g lacks an exception specification.  A special case of this is
|>         where g is a function written in another language, e.g., anything
|>         in the standard C library.  Recall that functions without exception
|>         specifications may throw anything.
|> 
|>     2.  f is a template function.  In this case, f must be instantiated
|>         using some unknown type T, and it is highly likey that f will
|>         invoke some T-specific function (e.g. member function of class T).
|>         However, there is no way to know what the exception specifications
|>         are on the T-specific functions.
|> 
|>     3.  f is a virtual function, because f may be redefined in a subclass
|>         by some function f' that contains an incompatible exception
|>         specification.  Recall that an exception specification is not part
|>         of a function's type.
|> 

I don't think (1) and (2) are real problems; the funtion f should catch all
exceptions except the ones it lists in its exception specification.

(3) is a real problem; either the rules on exception specifications as part
of the function signature need to be changed (a la Modula-3), or they won't
be very safe.  I'd rather see them done as in Modula-3 (but still allow the
default -- no specification -- to allow all exceptions to be thrown).

-- 
Matt Holiday                                      #include <std/disclaimer>
holiday@bnr.ca
BNR Richardson, TX