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

exceptions are generally uninformative #362

Open
radix opened this issue Nov 12, 2015 · 1 comment
Open

exceptions are generally uninformative #362

radix opened this issue Nov 12, 2015 · 1 comment

Comments

@radix
Copy link
Contributor

radix commented Nov 12, 2015

For example, when you get a NoNodeError, all we see is NoNodeError((), {}), when NoNodeError("/path/to/node") would be much more useful.

This is because exceptions are handled in a completely generic way by the protocol-level code; instead of the create function checking a response code and creating a NoNodeError(path), we have, in serialization.py, response = EXCEPTIONS[response](), and that part of the protocol code doesn't have access to any useful information to provide to the exceptions.

Related, the EXCEPTIONS dict for some reason is not made up of the classes directly, but rather little wrapper functions that look like this:

        def create(*args, **kwargs):
            return klass(args, kwargs)

I have no idea why; it almost seems like a mistake that it was defined to return klass(args, kwargs) instead of klass(*args, **kwargs), or of course, more simply foregoing the create function entirely and just putting the klass directly into the EXCEPTIONS dict.

@harlowja
Copy link
Contributor

Seems like a good change to have to me, want to make a PR with these?

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

No branches or pull requests

3 participants