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
On Fri, 2007-10-05 at 04:13 +0000, Andrew Bennetts wrote: error", but
> 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_
> 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 be_remoted
default implementation of can_be_remoted that returns e.g.
self._can_
-Rob www.robertcolli ns.net/ keys.txt>.
--
GPG key available at: <http://