structured way to remote exceptions

Bug #148463 reported by Martin Pool
10
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: hpss
Revision history for this message
Andrew Bennetts (spiv) wrote :

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.

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 148463] Re: structured way to remote exceptions

On Fri, 2007-10-05 at 04:13 +0000, Andrew Bennetts wrote:
> 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.

I think a flag is sufficient and easier to use.

If you want a method, for dynamically deciding, then at least offer a
default implementation of can_be_remoted that returns e.g.
self._can_be_remoted

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Revision history for this message
Martin Pool (mbp) wrote :

See also jml's comments in bug 118737

Revision history for this message
Martin Pool (mbp) wrote :

The point of bug 118737 is that we also need a structured or systematic way to send the exception parameters across the wire.

Exceptions that are likely to be caught and interpreted by the proxy Remote object, may need to be interpreted by examining their parameters, like the path of the affected file.

It's not easy to pass across parameters that might refer to other in-memory objects, but in most cases we only care about strings. (Should check)

Most Bazaar exceptions construct their string form on demand based on the parameters. If we're going to reconstruct a real new exception on the client, we presumably need to pass all the parameters used in the string template - this seems cleaner anyhow.

Jelmer Vernooij (jelmer)
tags: added: hpss
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
tags: removed: check-for-breezy
Changed in brz:
status: New → Triaged
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.