Re: Do you have experience with exceptions?
* DeMarcus:
If you want to design your own exceptions there are several guidelines
out there. One of them is this from boost.
http://www.boost.org/community/error_handling.html
If you look at their recommendations I would like to skip all items and
just focus on item 6. In short it says; in the exception, don't provide
messages, provide objects involved with the problem.
I claim that this is (almost) completely wrong, and my arguments for
this are the following.
*) A function may throw several different exceptions of the same type,
making it impossible for the receiver to understand what the attached
objects mean. E.g. OutOfBoundsException with an attached integer 42 may
mean that the loadModuleWithID() tried to load an ID that doesn't exist,
or it may mean that a subroutine to loadModuleWithID() tried to read out
of bounds in an XML file.
*) If a short message is created and attached to the exception, an
exception message stack unwinding may be more descriptive than what the
handler can put together on its own. E.g. it would probably be more
descriptive to see the following.
OutOfBoundsException - Tried to read XML section 42. Only 40 exist.
FileReadException - Could not read XML file config.xml.
NoSuchEntryException - Could not load module with ID 4711.
instead of
NoSuchEntryException - Out of bounds: 42. File: config.xml. ID: 4711.
*) Lower coupling promotes program correctness. If the receiver of an
exception has to understand the meaning of the attached objects, that in
turn means that we couple the function and caller. If the creation of
the exception changes slightly in the function, all callers have to be
updated!
Yeah, agreed. Good points. Especially last one.
I claim that a stack of independent exception messages is more
descriptive than trying to forward objects that an exception handler
shall interpret.
Do you have concrete examples from your experience with exceptions? I
would like to hear your opinion, especially if you don't agree with me.
Constructing an exception object shouldn't throw, or should have very low chance
of throwing. This means that designing your own /safe/ exception class is hard:
you first have to design and implement a reasonable array smart pointer, then a
reasonable non-mutable string class, then exceptions -- and there's a catch 22
for how to deal with exceptions for the string class...
Exceptions need not support chaining but they do need to support cloning and
rethrowing via some virtual method, in order to propagate exceptions safely
through C code.
The focus on providing a lot of information via exception objects is as I see it
wrong-headed for C++ (although it can be meaningful in a scripting context). In
C++ bugs should IMO preferentially trigger asserts, not raise exceptions, and
for a failure-indicating exception the type should be enough (and often is much
more than enough) for the handling code. A decent C++ debugger lets you break on
first throw, and that's where you're headed anyway when it's a bug. All that
information-gathering and forwarding for a "rich" exception is mostly additional
things that can go wrong, and it adds complexity & inefficiency.
Cheers, & hth.,
- Alf