EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Fwd: 3.15 C++ Exception classes
From: Kay-Uwe Kasemir <[email protected]>
To: Core talk list <[email protected]>
Date: Tue, 21 Feb 2006 12:00:07 -0500
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  <20062007  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  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·