[IPython-dev] ipython1 saw exception transport and raising

[Doug Jones]

Hi Brian,

Thanks for looking into this. I did the svn up and tested it and
everything looks fine now. The  result is more or less the same as
what I cooked up, meaning the name of the original exception is
displayed in the traceback.

However, there still seems to be some data loss in the process. Let me
demonstrate what I mean.

If I use my module in IPython itself and do something that I know
invokes an exception from some code that uses Boost.Python, I get
output like so:

In [3]: a = attribute_random()
---------------------------------------------------------------------------
Boost.Python.ArgumentError                             Traceback (most
recent call last)

<cut traceback>

ArgumentError: Python argument types in
    _basin.attribute_random()
did not match C++ signature:
    attribute_random(int b, unsigned int seed)
    attribute_random(std::vector<int, std::allocator<int> > b,
unsigned int seed)

I've included this to give you some insight to how this particular
Exception is formed:

In [2]: try:
   ...:     a = attribute_random()
   ...: except Exception, inst:
   ...:     print type(inst)
   ...:     print inst.args
   ...:     print inst
   ...:
<type 'instance'>
('Python argument types in\n    _basin.attribute_random()\ndid not
match C++ signature:\n    attribute_random(int b, unsigned int seed)\n
   attribute_random(std::vector<int, std::allocator<int> > b, unsigned
int seed)',)
Python argument types in
    _basin.attribute_random()
did not match C++ signature:
    attribute_random(int b, unsigned int seed)
    attribute_random(std::vector<int, std::allocator<int> > b,
unsigned int seed)

Now, when this same Exception is generated in a remote session, I get
output like so:

In [6]: a = attribute_random()
2007/07/16 13:56 -0400 [-] Performing execute on all
---------------------------------------------------------------------------
ipython1.kernel.error.UnpickleableException
Traceback (most recent call last)

<cut traceback>

UnpickleableException: ipython1.kernel.error.UnpickleableException:
***************************************************************************
An exception occurred in the IPython Interpreter due to a user action.
This usually means that user code has a problem in it somewhere.

engine: 1
method: execute(lines)
lines = a = attribute_random()

A full traceback from the actual interpreter:
---------------------------------------------------------------------------
Boost.Python.ArgumentError                             Traceback (most
recent call last)


ArgumentError:
***************************************************************************

As you see, some of the information that is part of the ArgumentError
is either not transported or not displayed. Unlike last time, I don't
really have any ideas as to why.


Thanks,
~Doug

On 7/12/07, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Doug,
>
> Can you do an svn up and try again.  You patch made it pretty clear
> what the problem was.  However, I did make some changes to make sure
> that the new type and value are something other than a string.  Here
> is what I committed:
>
> def packageFailure(f):
>     """Clean and pickle a failure preappending the string FAILURE:"""
>
>     f.cleanFailure()
>     # This is sometimes helpful in debugging
>     #f.raiseException()
>     try:
>         pString = pickle.dumps(f, 2)
>     except pickle.PicklingError:
>         # Certain types of exceptions are not pickleable, for instance ones
>         # from Boost.Python.  We try to wrap them in something that is
>         f.type = UnpickleableException
>         f.value = UnpickleableException(str(f.type) + ": " + str(f.value))
>         pString = pickle.dumps(f, 2)
>     return 'FAILURE:' + pString
>
> Let me know how this works - I don't have Boost.Python installed so I
> can't reproduce your situation exactly.  I can modify it further if
> needed.
>
> Brian
>
> On 7/9/07, Doug Jones <dfj225 at gmail.com> wrote:
> > Hello IPython devs,
> >
> > I've been testing the ipython1 saw branch and was testing some of the
> > new exception handling code. All in all, it seems to be working very
> > well, but I have come across one quirk that affects my code. Part of
> > the system that I use involves C++ code wrapped using Boost.Python.
> > For some reason, it seems that Boost.Python likes to create its own
> > classes for exceptions which aren't able to be pickled. So, whenever
> > one of these exceptions gets generated, I get a traceback about failed
> > pickling instead of the actual error that was generated.
> >
> > I cooked up a little change that makes these types of errors able to
> > be serialized. I'm not too familiar with the internals of IPython1, so
> > there might be a much better way to do this, but at the very least I
> > hope my code serves as a good indication of where the problem lies.
> >
> > Thanks,
> > ~doug
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
>