[py-dev] Request for enhancing Exception handling in execnet

Guido Wesdorp johnny at johnnydebris.net
Tue May 6 09:38:20 CEST 2008


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



More information about the Pytest-dev mailing list