-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Logging caught exceptions #73
Comments
why isn't the original traceback visible? the locally-raised exception has an attribute called unless you disabled |
I think the phrasing of the original issue description was not clear enough. We mean that in addition to the _remote_traceback attribute (which is great), it would be nice to have rpyc's logging include a debug log of the traceback caught by the dispatch layer. This is just to aid debugging, as the _remote_tb is not printed out by default, and in some cases we understand we should have printed it only when it's too late and the exception object itself is gone. In such cases, however, the rpyc log can be kept on the remote host. One other way of putting it - it's hard to control all paths calling into a remote rpyc server, but it's easy to control the server itself when it's being first run. |
See also #74 |
duplicates #74 |
the changes are the following:
could you please test that it works as expected? |
So this means the connection object also logs exceptions? |
only the connection object logs exceptions: the server just sets the logger: |
Oh - I was confused - thought you meant the client side connection. Great. |
It would be very useful for debugging if the serialized exceptions will be logged on the 'server side' with their traceback, since the original traceback isn't visible on the 'client side'.
The text was updated successfully, but these errors were encountered: