🚀 go-pugleaf

In article <9511120523.14310@mulga.cs.mu.OZ.AU>,
   fjh@munta.cs.mu.OZ.AU (Fergus Henderson) wrote:
>herbs@interlog.com (Herb Sutter) writes:
>>While we're on the subject of exception handling, is there any technical
>>reason not to have an exception spec on every member function of every
class?
>
>There is at least one technical reason - it won't work with template
>classes.  Consider, for example, the member functions of the STL
>collection classes.  What exception specification should they have?
>It depends on what exceptions can be thrown by the Allocator class
>and the collection element type.  C++'s exception specifications
>don't provide a way to express that.

Hmm... good point, but while this is a good argument in the case of collection
classes, is it necessarily true of all template classes?

The way I see it, having a class X be a template that uses unknown classes may
not be substantially different from having a class X that uses a known class
B, for not only may B's exceptions change over time but, more realistically, B
may later (unknown to X) be polymorphically extended to derived classes that
throw different exceptions... yes, I know this is heresy and bad design, but
the derived classes may not be able to help it in all cases (e.g. when the
derived class provides an overridden service by using a third-party library,
whose exception-throwing can't be controlled).  The only difference is where
the ex-spec might reasonably be declared:

case 1:    template<class T> struct X1 { void f(T) throw(???); }

case 2:    class B;          struct X2 { void f(B) throw(???); }

In case 1, X1::f() can have no real idea of what exceptions may be thrown.  In
case 2, even if B has full ex-specs, X2::f() may have a better idea but in the
long run also cannot be certain no unexpected/unknown exception will be
thrown, because it could be given some object of a class derived from B.

In either case, ought we to simply throw up our hands and say, 'it's too
difficult'?  Granted, case 1 is different because it's truly 'wild and wooly'
in terms of anticipating exception types, but even in this case I'd argue that
ex-specs should appear, not in X1::f() directly perhaps, but in all code that
uses X1::f() -- because whether that 'using' code is end-user code or another
class in our own object model, that 'using' code has to know what exceptions
may arise since it's the code that instantiates the template, so if nothing
else we can foist off responsibility on it since it ought to know.  (Caveat:
unfortunately, using code probably will also have to know something about the
_implementation_ of X1::f() to know what exceptions to expect, which means in
the case of templates there may be a tension between exception specification
and encapsulation.)

The more I look at this, the more I think we cannot have true exception safety
unless there is an ex-spec on every function and member function in every
piece of code we write; templates are a special case, but even with templates
the ex-spec ought to go where it belongs, in the 'using' code that does know
the type and therefore should know what exceptions to expect.  To make this
possible, though, the template must document what services of the templated
type will be used (e.g. "X1<T>::f() may use T::func1() and T::func7()").


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]