D
DeMarcus
Hi,
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!
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.
Thanks,
Daniel
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!
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.
Thanks,
Daniel