Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Tue, 21 Feb 2006 10:51:25 -0500

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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System