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.
For example, when you get a NoNodeError, all we see is
NoNodeError((), {}), whenNoNodeError("/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
createfunction checking a response code and creating aNoNodeError(path), we have, inserialization.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
EXCEPTIONSdict for some reason is not made up of the classes directly, but rather little wrapper functions that look like this:I have no idea why; it almost seems like a mistake that it was defined to return
klass(args, kwargs)instead ofklass(*args, **kwargs), or of course, more simply foregoing thecreatefunction entirely and just putting the klass directly into theEXCEPTIONSdict.