Define exceptions for `ctp7_modules`

[jsturdy]

Brief summary of issue

Should have a generic exception class, with derived specific exceptions for various failures we would like to catch in the execution of ctp7_modules

Has been variously discussed in #109 and #85

This work should be able to progress independently of @lmoureaux's work on passing the exceptions through the templated RPC calls in xhal

Types of issue

• [x] Feature request (request for change which adds functionality)

Expected Behavior

Definition of all exceptions thrown by ctp7_modules that will be converted by @lmoureaux's work in xhal in conjunction with the templated RPC calls These exceptions can then be caught in the host calling code, e.g., cmsgemos by the same name, and simply by including the exception definition file.

[lmoureaux]

This work should be able to progress independently of @lmoureaux's work on passing the exceptions through the templated RPC calls in xhal

If the same exception has to be rethrown on the caller side, a list of all supported classes would be needed. Template magic isn't impossible but I don't think it's worth the additional complexity.

In my test implementation, a remote call can throw two exceptions:

// When an exception is thrown by remote code
class RemoteException : public std::runtime_error
{
public:
    // what() is essentially forwarded from the caught exception
    bool has_type() const; // Type can be absent in some cases (eg out of memory)
    std::string type() const; // eg "std::bad_alloc"
    bool has_backtrace() const; // Backtrace would be present in debug mode (need to LD_PRELOAD a small .so)
    std::string backtrace() const;
};
// Decoding error (instead of wiscrpc exceptions that don't derive from std::exception)
class MessageException : public std::runtime_error
{
    // Only what()
};

Should have a generic exception class

I'm going to assume that all exception thrown by the modules themselves derive from std::exception. You'll see that supporting all wiscrpc exceptions isn't straightforward, I don't want do add more complexity to that.

[jsturdy]

I am expecting to have the ctp7_modules all have a common exception base type to ensure they all throw something derived from that (even in the case that they have to catch something from wiscrpc and wrap it with an "in framework" exception) I was naively imagining something a la the derived exceptions in our xdaq code... I think in all the methods that I had added exceptions to, the exceptions are std::runtime_error, but I'm not certain

[lmoureaux]

I am expecting to have the ctp7_modules all have a common exception base type to ensure they all throw something derived from that (even in the case that they have to catch something from wiscrpc and wrap it with an "in framework" exception)

They will probably also throw standard library exceptions, so the simplest possible catch is:

try {
    // Something
} catch (const std::exception &e) {
    std::cout << e.what() << std::endl;
}

That's basically why I like deriving directly or indirectly from std::exception (std::runtime_error is a good choice).

I was naively imagining something a la the derived exceptions in our xdaq code...

The hierarchy under std::exception is similar to that, but xDAQ and wiscrpc exceptions don't derive from the standard ones :-1:. I'd avoid needlessly multiplying the number of classes (you can see how broad they are in the standard library), but in the end it's more a matter of taste.