Experimental Physics and Industrial Control System
|
Kay-Uwe Kasemir wrote:
On Feb 21, 2006, at 11:36 , Andrew Johnson wrote:
Actually, Benjamin did, and as I said in my reply to his message, can we
keep this conversation on core-talk please. Private conversations make
these discussions harder to follow, and break up the archive of what was
said.
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
--
There is no S in exprexxo.
- References:
- Re: 3.15 C++ Exception classes Andrew Johnson
- Navigate by Date:
- Prev:
Fwd: 3.15 C++ Exception classes Kay-Uwe Kasemir
- 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:
Fwd: 3.15 C++ Exception classes Kay-Uwe Kasemir
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|