You must still call the callback after calling setFailed(), but the message passed to the callback may be ignored. Unfortunately this interface is kind of messed up right now. We'd like to change it so that the callback has two methods: one for normal return and one for failure.
On Wed, Oct 14, 2009 at 1:06 PM, Evan Jones <[email protected]> wrote: > > I know this is somewhat implementation dependent, but I'm wondering > what the intention of RpcController.setFailed is: Does the > implementation need to call the callback still? Or should this > immediately "return" on the client side? > > My interpretation is that the implementation should still need to call > the callback, as this would allow you to *both* setFailed() and return > a result, which might be useful, or call setFailed() and call the > callback with null. > > However, I can also argue that a failed RPC does not return results > because it failed, so calling setFailed() should cause the RPC to > return on the client. > > Any thoughts? > > Thanks, > > Evan Jones > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
