I am not convinced, neither by the argument above ("write a try/
catch phrase that could catch warnings but not errors or
fatalities") nor by the Jeff's design where the severity is a class
member.
IMHO, exceptions should not be classified at all into severity types.
Instead, I would propose to create /one/ special exception type that
is reserved for 'assert' style failures, i.e. failures that can only
becaused by broken or corrupted code. IIRC, this is what a 'fatal'
severity normally means in Jeff's code.
All other exceptions are normal (i.e. expected) failure conditions.
Warnings, OTOH, can be automatically logged or whatever, but should
NEVER cause an exception to be thrown. For exceptions to be useful
in any way it is of utmost importance to strictly separate between
success and failure. If the requested operation can be (and is)
performed in any way, an exception must / not/ be thrown.
Absolutely. Exceptions are errors from which one can only recover
by backing off, displaying the message and leaving the rest to the user.
Warnings are not exceptions.
There are certainly libraries which like to turn their exception
hierarchy into
dissertation matter, but I don't even see the need for a distinction into
FatalException or NormalException.
What does this code
try
{
loadDatabase("xy.db")
}
catch (FatalException &e)
{
...print "FatalException: " + e.what();
}
catch (NormalException &e)
{
...print "NormalException: " + e.what();
}
with end user messages ala
"FatalException: Divide by 0, null pointer, array overflow, ...."
or
"NormalException: Syntax error in line 42 of 'xy.db'.
offer to the user that you don't get from
try
{
loadDatabase("xy.db")
}
catch (exception &e)
{
...print e.what();
}
?
In both cases, the user wanted to load "xy.db",
can't, and has to figure out why.
Passing a meaningful string for what() is the key.
-Kay
