In our company, we're trying to formulate a number of rules about the use
of exceptions.  Specifically, we're trying to figure out how to avoid long
exception specifications by using inheritance.

The idea is to derive all the exceptions we have from one of the standard
classes runtime_error and logic_error (both of which are directly derived
from class exception).  A handler for runtime_errors is allowed to retry a
failing operation; a handler for logic_errors must re-throw the current
exception, so the program will eventually terminate.

Our hope is that by enforcing these rules, we can avoid exception
specifications with more than two exception types.  However, when we
checked the April '95 DWP, we ran into trouble because the predefined
exception types bad_alloc, bad_cast, bad_exception, bad_typeid and
ios_base::failure are directly derived from the standard exception class.
This implies that the number of exception types that an exception handler
must know about when determining if an operation can be retried is at least
seven instead of just two.

Regarding this, I have two questions:

(1) Is it the committee's intention to encourage developers and library
vendors to define all exception classes as subclasses of either
runtime_error or logic_error?
(2) If so, then why are the other exception types defined in the standard
directly derived from class exception?

Another issue that came up is the use of plain (non-virtual) base classes
in the standard exception hierarchy.  Several books warn about possible
ambiguities when using such classes, the canonical example being:

        class MyTrouble : public runtime_error { /* ... */ };
        class YourTrouble : public runtime_error { /* ... */ };

        class OurTrouble : public MyTrouble, public YourTrouble
                { /* ... */ };

        void f()
        {
                throw OurTrouble();
        }

        void g()
        {
                try {
                        f();
                }
                catch (const runtime_error& re) {
                        // What did we catch? MyTrouble::runtime_error
                        // or YourTrouble::runtime_error?
                }
        }

So far, I have never seen a case where non-virtual inheritance for
exception classes makes sense.  So my final question is:

(3) Why don't the standard exception classes use virtual inheritance?

Thank you,

- Wil


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 26006027@ittpub.nl, clamage@taumet.eng.sun.com (Steve Clamage) writes:

>In our company, we're trying to formulate a number of rules about the use
>of exceptions.  Specifically, we're trying to figure out how to avoid long
>exception specifications by using inheritance.  ...

Except I didn't write it. The orginal sender was "wil@ittpub.nl".
Evidently his news server doesn't insert a proper "From" field.

---
Steve Clamage, stephen.clamage@eng.sun.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]