google
Consider error story
Update: I've torn out all custom errors for now and am just using io::Error for errors in the framework stack. This is not intended to be super long-term, but I also don't have any short-term plans to fix it.
service!s are still free to use whatever error types they want. In practice, this means that if you define rpc foo() -> Result<Bar, CustomError>;, then await!(client.foo(context::current())) evaluates to type io::Result<Result<Bar, CustomError>>. This isn't great, but I also don't feel awful about it, because I think users will typically just propagate the io::Error with the ? operator.
Other options:
- Require rpc definitions to always specify a result type, and require the error type to
impl From<io::Error>(orFrom<tarpc::Error>, if I ever do that).
This feels like a hindrance to users doing simple things without results, like rpc foo() -> String;. Also, it's unclear to me that I could come up with a tarpc::Error that is any better than io::Error, because it's still going to be a grab-bag of failure modes.