🚀 go-pugleaf

fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
: sakkinen@jyu.fi (Markku Sakkinen) writes:
: 
: >I am afraid that distinguishing exceptions only by the type of the
: >'throw' expression is mostly overkill instead of improvement.
: >Suppose for instance that you have 20 distinct exceptions,
: >which only need to pass an integer's worth of information
: >to their handlers (or perhaps no data at all).
: >You have to declare a class for each of them.
: 
: Is this so difficult?
: 
: 	class MyException : Exception {};
: 
: 	struct MyIntException : Exception {
: 	    int value;
: 	    MyIntException(int value_) : value(value_) {}
: 	};

Note that Markku said distinguishing exceptions only by the type.
                                                ^^^^
The alternative to class MyIntException with 20 distinct instances
is 20 subclasses to MyIntException (which IMHO _is_ overkill).

I do not advocate a single exception class, it just seems to me that
the exception class hierarchy runs the risk of being overused for too
many tasks:

1 data representation		(MyIntException,MyStringException)
2 exception gravity		(MyErrors, MyWarnings)
3 identifying specific errors	(MyClassIsIllBecauseTheMoonIsFull)
4 identifying the throwing class(ios::failure, MyBase::failure)

Combined with exception specifications (throw clauses), I think this
proliferation of exception classes can be quite a maintenance problem,
unless the exception hierarchies are very carefully designed (using MI).

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------