Boost.Python Custom Exception Class

I'm implementing a Python extension module using Boost.Python. The module should define its own custom exception classes that inherit Exception. How do I do that?

Solution 1:

The following function creates a new Python exception class and adds it to the current scope. If it is called in a module initialization function, then it is added to the module.

The first argument is the name of the new exception class. The second argument is the type object for the base class of the new exception class; it defaults to the type object for Exception. The return value is the type object for the new exception class.

PyObject* createExceptionClass(const char* name, PyObject* baseTypeObj = PyExc_Exception)
{
    using std::string;
    namespace bp = boost::python;

    string scopeName = bp::extract<string>(bp::scope().attr("__name__"));
    string qualifiedName0 = scopeName + "." + name;
    char* qualifiedName1 = const_cast<char*>(qualifiedName0.c_str());

    PyObject* typeObj = PyErr_NewException(qualifiedName1, baseTypeObj, 0);
    if(!typeObj) bp::throw_error_already_set();
    bp::scope().attr(name) = bp::handle<>(bp::borrowed(typeObj));
    return typeObj;
}

Use the function as follows:

Call the function in the module initialization function and store the return value in a global variable:

PyObject* myExceptionTypeObj = 0;

BOOST_PYTHON_MODULE(MyModule)
{
    ...
    myExceptionTypeObj = createExceptionClass("MyException");
    ...
}

Raise exception of type MyModule.MyException:

PyErr_SetString(myExceptionTypeObj, "Oh my!")

Solution 2:

@Kenny:

If you refer to

PyErr_SetString(myExceptionTypeObj, "Oh my!")

I wouldn't regard this as "copying the string to a global object". Rather, it sets Python's internal error indicator so that the interpreter will raise an instance of myExceptionTypeObj at its next error indicator check.

Python's exception handling works with a (per Python thread) global error indicator and this is the usual way to raise an exception through the C API afaict.

My take on it is you're safe if your holding the GIL at this moment and will properly cause an exception in the Python thread your C code was entered from.