Skip to content
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

Closed
grzn opened this issue May 2, 2012 · 8 comments
Closed

Logging caught exceptions #73

grzn opened this issue May 2, 2012 · 8 comments

Comments

@grzn
Copy link
Contributor

grzn commented May 2, 2012

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'.

@tomerfiliba
Copy link
Collaborator

why isn't the original traceback visible? the locally-raised exception has an attribute called _remote_tb which holds the traceback of the exception that happened on the server, e.g., http://rpyc.sourceforge.net/tutorial/tut2.html#exceptions

unless you disabled include_local_traceback. see http://rpyc.sourceforge.net/api/core_protocol.html#rpyc.core.protocol.DEFAULT_CONFIG

@vmalloc
Copy link
Contributor

vmalloc commented May 3, 2012

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.

@vmalloc
Copy link
Contributor

vmalloc commented May 3, 2012

See also #74

@tomerfiliba
Copy link
Collaborator

duplicates #74

tomerfiliba added a commit that referenced this issue May 3, 2012
@tomerfiliba
Copy link
Collaborator

the changes are the following:

  • connection: a logger object can be set in the config dict; if it's not None, it will be used to log the exception.
  • server: if no explicit logger is given in the protocol_config, the server will set the logger to its own internal logger. this way, different servers will log to different loggers

could you please test that it works as expected?

@vmalloc
Copy link
Contributor

vmalloc commented May 3, 2012

So this means the connection object also logs exceptions?

@tomerfiliba
Copy link
Collaborator

only the connection object logs exceptions:
d646749#L0R305

the server just sets the logger:
1ffcc44#L0R85

@vmalloc
Copy link
Contributor

vmalloc commented May 3, 2012

Oh - I was confused - thought you meant the client side connection. Great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants