Gerard Petersen wrote:
> Errors on the remote side are raised
> as OSErrors and contain a textual version of the remote exception.
They are actually raised as RemoteError
(py.__.execnet.channel.RemoteError) instances, but I understand the
frustration. The RemoteError instance doesn't hold a reference to the
original error, which can be annoying.
I think one of the problems could be that the remote exception may not
be valid on the local machine: for instance if you import a library
'foo' that raises a (self-invented) FooException on the remote side,
that library may not be available locally so it may be that FooException
can not be instantiated/raised there. I'm not sure how to deal with this
problem. I do know execnet has the possibility to pickle (?) and send
over exceptions, though...
I think what you could do in your code is catch the specific exceptions
you're interested in on the remote side yourself, and send those over
the channel if something goes wrong, rather than the data you would have
sent if it would have succeeded. Of course this means that both the
client and the server (never sure which is which, though ;) will become
more complex, but I don't think it's too bad:
g = py.execnet.PopenGateway()
g.execute("""\
import os
try:
l = os.listdir('/some/dir/that/may/have/problems')
except OSError, e: # could even be 'Exception' instead of 'OSError'
channel.send(e)
else:
channel.send(l)
""")
ret = channel.receive()
if isinstance(ret, Exception):
raise ret # raise the remote exception again
assert isinstance(ret, list) # here you know 'ret' is a list
I understand this isn't optimal, and doesn't solve the problem entirely
(just for the exceptions you deal with explicitly), but at least you can
now get back to work again... ;)
Cheers,
Guido
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
