🚀 go-pugleaf

Raymond Fergerson (rwf@camis.stanford.edu) wrote:
|> My understanding is that the current ANSI draft specifies a 
|> number of standard exceptions which form an
|> inheritance forest, but not a tree:  there is no common root.
|> I also heard that this choice was the subject of much debate at
|> the meetings.  Could someone please present a summary of the 
|> arguments both for and against using a tree structure for the 
|> standard exception hierarcy.  Did Stroustrup express an opinion 
|> on this subject, and, if so, which way did he lean? Was multiple 
|> inheritance in the use of exceptions the big issue?

As far as I can see, all of the exceptions thrown by the standard
library derive from the class exception, so they form a tree, not a
forest.

This seems logical to me; the isA relationship definitly holds, and
there is a fundamental relationship (as opposed to the case of an Object
class, from which everything derives).  I would even suggest that unless
there were very strong motives for doing otherwise, applications base
their exception hierarchy on the one used by the standard library.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
              -- A la recherche d'une activité dans une region francophone

---
[ 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. ]

In article <47va08$8lb@gabi.gabi-soft.fr>,
   kanze@gabi-soft.fr (J. Kanze) wrote:
>As far as I can see, all of the exceptions thrown by the standard
>library derive from the class exception, so they form a tree, not a
>forest.
>
>This seems logical to me; the isA relationship definitly holds, and
>there is a fundamental relationship (as opposed to the case of an Object
>class, from which everything derives).  I would even suggest that unless
>there were very strong motives for doing otherwise, applications base
>their exception hierarchy on the one used by the standard library.

I notice this isn't covered in Cline's online FAQ, but it is covered in his 
book (highly recommended: "C++ FAQs", Addison-Wesley, 1995, ISBN 
0-201-58958-3).  See Section 21, "Tactical Advice for Exception Handling", 
where the very first entry (FAQ #261) launches right into this question.

BTW, I concur heartily with James' last remark.  At the moment I can't imagine 

a motive for doing otherwise, actually, that couldn't be solved by simply 
gathering your own exceptions under a root that's derived from 'xmsg' (or 
'exception'? is that the correct DWP name?) and ignoring the fact that you're 
in the tree when you want to ignore it.

Herb


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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. ]

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. ]