structured way to remote exceptions
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
Medium
|
Unassigned | ||
Breezy |
Triaged
|
Medium
|
Unassigned |
Bug Description
affects bzr
importance medium
status confirmed
When an exception occurs during processing a request in the smart
server, we want to report that back to the client. At the moment this
is handled case by case in smartserver methods. It seems like it would
be better if they were caught and reported back to the client at a
higher level.
Issues:
* exceptions that contain arbitrary objects can not easily be passed
across the network; we probably want to stringify their attributes
* older clients may not have all the exception classes that can be
raised by newer servers
* clients do want to know the exception class; they may want to examine
the attributes but may be able to cope with the string forms.
just passing the complete stringified exception is not enough.
* eventually, we'd want internationalized exceptions, which could be
done on either the client or server
* it might not be appropriate to send back all exceptions
* internal errors on the server should be logged
Proposal:
* catch errors in the smartserver framework
* internal errors are logged and a generic message is given back to the
client
* user errors and sent back as an exception class name plus list of
stringified arguments
* if the client recognizes the class name as a user error it
reconstitutes and raises one; otherwise it raises a generic remote
error
We may also want the protocol to more clearly distinguish errors from
other results.
--
Martin
tags: | added: hpss |
tags: | added: check-for-breezy |
tags: | removed: check-for-breezy |
Changed in brz: | |
status: | New → Triaged |
importance: | Undecided → Medium |
I like this plan.
After chatting with Martin, I think a small improvement would be to add a new method to BzrError called something like "can_be_remoted". The default implementation could be just "return self.internal_ error", but this gives us a clear way to allow or disallow specific exceptions on the wire, rather than just assuming all user errors can be sent.
I'm tempted to say that all errors that can be sent should be explicitly listed somewhere, so that a third-party implementation of the protocol can know what is possible, but I think a "can_be_remoted" method is close enough.