Traceback lost?

Running a name server:

python -m Pyro4.naming

Having the following server.py:

import Pyro4


class Test(object):
    def test(self):
        return int('a')


if __name__ == '__main__':

    daemon = Pyro4.Daemon()
    ns = Pyro4.locateNS()
    uri = daemon.register(Test)
    ns.register("test", uri)

    print("Ready.")
    daemon.requestLoop()

And having the following client.py:

import Pyro4


if __name__ == '__main__':

    proxy = Pyro4.Proxy("PYRONAME:test")
    proxy.test()

This code basically ends up executing int('a'), which in Python should raise:

ValueError: invalid literal for int() with base 10: 'a'

The ValueError is raised when running client.py, however, the traceback looks like this:

Traceback (most recent call last):
  File "client.py", line 7, in <module>
    proxy.test()
  File "/home/peque/.miniconda3/envs/pyro4/lib/python3.5/site-packages/Pyro4/core.py", line 172, in __call__
    return self.__send(self.__name, args, kwargs)
  File "/home/peque/.miniconda3/envs/pyro4/lib/python3.5/site-packages/Pyro4/core.py", line 427, in _pyroInvoke
    raise data
ValueError: invalid literal for int() with base 10: 'a'

Note that client.py:7; proxy.test() is represented, but there is no reference to server.py:6; return int('a'), which is the line in which the exception actually occurred.

Am I missing something or is this actually not supposed to happen?

Thanks for your help. 😊

[irmen]

@gst it is convenient I agree, but consider the arguments on the table already. Pyro is a generic library and as such it should not print arbitrary messages or interfere with global Python errorhandling. If you want this, you should do it in your application code itself. Pyro provides some tools (the exception hook in util, the getPyroTraceback method or the possibility to create your own proxy subclass to customize the behavior like what Peque showed above) to make this easier if your code wants it, but ultimately, it leaves it up to you to enable them in your own client application code.

[irmen]

@gst that’s because the exception is raised on the local side (it’s your local client code that encountered an error). This is what would happen if you were doing a normal python function call, and Pyro doesn’t interfere with that. The special thing about Pyro is that there is a remote party involved, hence the special method / exception hook to retrieve that additional part of the error