Gottfried.Ganssauge@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