Experimental Physics and Industrial Control System
Hi:
I think that all C++ exceptions should look as similar to the
std::exception as possible.
I agree with Andrew that this means:
- The type tells you what happened,
no need for additional getSeverity().
(more on the type tree below).
- what() gives a user-readable message.
There, I would actually require the specific
const char *what();
because that's what std::exception happens to use.
The archiver is being reworked to use something like this:
class GenericException : public std::exception
{
public:
/// Construct with file, line info and printf-type arguments.
GenericException(const char *sourcefile, size_t line, const char
*format, ...)
__attribute__ ((format (printf, 4, 5)));
/// Retrieve an explanatory string.
/// Default implementation will print source file and line.
virtual const char *what() const throw ();
};
... because I happen to like source & line info as well as a printf-type
interface for generating the message,
but the primary interface to that info is the what() that comes
with the std::exception.
So user code that simply uses
catch (std::exception &e)
{
... print e.what() ...
}
will have the benefit of source, line, detail information.
I don't actually think that much of a type tree is needed for catching
exceptions. Exceptions disrupt the flow of control because you have
to bail out for an unexpected, exceptional reason.
If it's something from which you can recover easily,
that's not meant to be an exception.
The best you can do with an exception is go back up to a level of code
where you can print the message and continue with something else.
-Kay
On Feb 20, 2006, at 18:21 , Andrew Johnson wrote:
Last September, Jeff Hill sent me this class definition, with the
suggestion that something like this be adopted as the basis for
future EPICS exception objects:
struct Diagnostic : exception {
public:
enum severity_t { sevWarning, sevError, sevFatal };
virtual severity_t severity () const = 0;
virtual void context ( StringSegment & ) const = 0;
};
Having recently committed my StringReader and StringEditor
interfaces and some implementations to the 3.15 CVS tree for Jeff
to use in DataAccess, I am looking at designing a modified version
of this class for general use. The main point of this email is to
document what I'm currently implementing, but I guess that this may
result in some discussion from Jeff and others as well.
severity(): I don't like this; the severity information should be
implicit in the hierarchy of the class that is being thrown. I
expect to be able to write a try/catch phrase that could catch
warnings but not errors or fatalities; I don't want to catch
everything and then have to re-throw anything that's more severe
than a warning. I'm also not convinced that the thrower can
determine the severity of an exception in practice. Therefore I'm
not going to include the severity part.
context(): I'm replacing Jeff's StringSegment with a StringEditor
and renaming this function to what(), since it performs the exact
same role as the std::exception::what() function, namely provides a
way to convert the exception data into a displayable string.
status(): We often provide wrappers to allow C code to call C++
code. The C routines can't trap exceptions, so those C++ wrappers
may have to convert such exceptions into a long integer status
value. The exception object is the obvious thing to know what
status value to return, so I'm considering adding this method to
provide that. If the conversion to the single C status value would
lose diagnostic data that is stored in the exception object, this
routine can log that information to the error logger at that time -
status() should only be called once, when the exception is about to
be passed to C code.
Here's my current replacement base class:
class BaseException :
public std::exception {
public:
virtual void what(StringEditor &str) const = 0;
virtual long status() const {
return S_exc_exception;
}
};
- Andrew
--
There is no S in exprexxo.
- Replies:
- Re: 3.15 C++ Exception classes Andrew Johnson
- References:
- 3.15 C++ Exception classes Andrew Johnson
- Navigate by Date:
- Prev:
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:
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