[C++-sig] Re: Wrapper for exception translation

[David Abrahams]

Gottfried.Ganssauge at HAUFE.DE writes:

> Currently, in order to wrap user defined exceptions you need to
>
> - allocate a python exception using PyErr_NewException

Well, no.  I don't see any call to PyErr_NewException in
libs/python/test/exception_translator.cpp

>   This function needs to be parametrized using a specific naming
>   convention

It's not clear to me what you're referring to.  Are you sure you mean
"naming convention"?

>   you also need to find a place where this exception instance lives
>   and is accessible to the exception translator

I don't know what you mean here.  For one thing, first "this" is a
function and now "this" is an exception instance.

> - define an exception translator which signals the exception defined
> above

What do you mean by "define an exception translator"?
What do you mean by "signals the exception"?

> - register the exception translator with the library

This I understand to mean something like:

     register_exception_translator<error>(&translate);

> My facility allows to do this with only one function call
> "exception_<Exception type> (name)" within the module init function.
> It will allocate a python exception 

Do you mean it will create a Python subclass of Exception?  Or is it
something else?  I guess the docs for PyErr_NewException are a little
unclear on this point, but I think it's what I said.

> and store it within an instance of the
> translated_exception_handler<> class. The name for that exception is
> taken from the name parameter and the current scope according to the
> naming convention documented in the manual page for
> PyErr_NewException.  

Hmm, I didn't know about PyErr_NewException, but it looks useful.

> A reference to the translated_exception_handler is stored within the
> class dictionary of the newly allocated python exception in order to
> keep the translator alive.  The translated_exception_handler
> provides the exception translator to be registered with the
> library. 

OK, OK, wait.  I was beginning to like where this was going, (I like
what you're accomplishing) but this all sounds *way* too complex for
that purpose.  Especially the "creation of an anonymous class" that
you do in the code here looks like a messy hack likely to break at
some point.  Why is such a complicated mechanism needed?

> It uses a generic method to obtain an exception description
> by calling a function get_exception_description<>() which has a
> default implementation in the detail namespace.  Finally the python
> exception itself is made available in the module's namespace under
> the name given.
>
> get_exception_description<>() currently returns a const char * which
> is passed to PyErr_SetString(). It might be worthwile to make it
> return an object which then could be passed to
> PyErr_SetObject(). This modification would make it possible to pass
> an instance of a class which wraps the exception caught, which again
> would make the exception instance itself available to python
> programs.
>
> Another enhancement could be the generation of derived python
> exceptions, an area in which I have no experience yet. This could be
> by an additional template parameter to the exception_<>() function
> which defaults to the allocation with PyErr_NewException().
>
> What do you think?

I think I understand this much:

  your code provides the ability to easily define new Python
  exception types corresponding to particular C++ exception types.

Bravo to that; I'd like to get this capability into the library.

I do think the implementation is needlessly convoluted.  Just by
inspection it looks to me like you make heavy use of a dictionary 

        // class dictionary for the new exception class
        dict d;

which later simply goes out of scope.  What's the point of that?
Have I missed something?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com