On 6/18/05, Denis S. Otkidach <[EMAIL PROTECTED]> wrote: > 2) You overwrite virtual method of wrapped class in Python, so that > other methods (implemented in C++) use it instead of base. This is more > interesting case, but I believe SIP can't handle it too. Please correct > me if I'm wrong.
Bingo. I use Python to implement abstract classes defined in Python. The calling C++ has no idea that it is ultimately calling into Python, thus there is no opportunity for checking the Python error state outside of the binding code. My existing C++ code is fairly heavily exception based. All error handling is done though exceptions which will cause database transactions to abort cleanly. The problem is when Python raises an exception (or calls back into some C++ code that throws an exception) control is returned to C++ which continues quite happily. Throwing anything would be an improvement in this case. I can see some sort of exception class defined in SIP for encapsulating Python errors. This would be thrown in response to your garden variety PyExc_* errors. If the exception coming from Python is a wrapped C++ type, then it can be unwrapped and thrown as the original type. I think the problem here is whether to throw it as a pointer or make a copy. Personally, I always catch references, so I would prefer the copy. That brings us back to the problem of copying exceptions. When SIP catches a matching exception, it makes a copy of the exception object, potentially discarding type information. (Isn't this where the thread started?) This precludes using the type at the root of an inheritance heirarchy in the exception specifier as shorthand for 'could throw anything derived from x.' James _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
