-
-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPC exceptions don't work as expected #602
Comments
I guess it happens because RPC server wraps any error from handlers to an exception, even if a returned error is already an error of type |
The current code does not handle decoding of prefixes. cc @kentonv, is there any interest in standardizing attaching arbitrary capnp structs to be attached to |
In the C++ implementation's |
Somehow, I have missed that in the RPC specification. Thanks. |
It's really tricky to understand, how can I return a logic exception to a client. At the moment we've got the
exc
package that should help us return meaningful errors to clients by settingType
andPrefix
to an exception, for instance let's create an instance ofFailed
type exception annotated with custom prefix, which I want my client to receive:Then, in a server handler, I'd like to send that created exception to a client:
And I expect my go-capnp client to receive that error, and it indeed receives it:
But when I cast received
err
to an exception, prefix in the cast exception is empty, so I can't match it directly to the root cause without some string parsing. See the following example:I might've been lost in terms of capnproto protocol errors handling and producing, but seems like clearly something is broken with exception prefixes. Or maybe I just didn't find how to properly parse exceptions :)
P.S. Regardless if this issue is a bug or not, I think we need to improve documentation for exceptions.
The text was updated successfully, but these errors were encountered: