Sorry, also sent this to Andrew on the first reply...
Begin forwarded message:
From: Kay-Uwe Kasemir <[email protected]>
Date: February 21, 2006 11:59:16 EST
To: Andrew Johnson <[email protected]>
Subject: Re: 3.15 C++ Exception classes
On Feb 21, 2006, at 11:36 , Andrew Johnson wrote:
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
- Navigate by Date:
- Prev:
Re: 3.15 C++ Exception classes Andrew Johnson
- Next:
Re: 3.15 C++ Exception classes Andrew Johnson
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: 3.15 C++ Exception classes Andrew Johnson
- Next:
Re: 3.15 C++ Exception classes Benjamin Franksen
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|