Skip to content
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

remove CallError #1087

Merged
merged 15 commits into from
Apr 21, 2023
Merged

remove CallError #1087

merged 15 commits into from
Apr 21, 2023

Conversation

niklasad1
Copy link
Member

@niklasad1 niklasad1 commented Apr 19, 2023

Close #1085

One downside of this is that jsonrpsee::core::Error can't be used in the proc macro API and I worked around that by changing type RpcResult<T> = Result<T, ErrorObjectOwned>

The reason why ☝️ is because the IntoResponse requires the error to implement Into<ErrorObjectOwned> which ends up being really weird to implement from Error variants that isn't really a JSON-RPC v2 spec error but something else like I/O etc.

Thus, it's more explicit for users to implement Into<ErrorObjectOwned> themselves which is explicit and more understandable.

@niklasad1 niklasad1 changed the title refactor: remove CallError WIP: remove CallError Apr 19, 2023
@niklasad1 niklasad1 marked this pull request as ready for review April 20, 2023 10:18
@niklasad1 niklasad1 requested a review from a team as a code owner April 20, 2023 10:18
core/src/error.rs Outdated Show resolved Hide resolved
core/src/lib.rs Outdated Show resolved Hide resolved
core/src/lib.rs Outdated Show resolved Hide resolved
@niklasad1 niklasad1 changed the title WIP: remove CallError remove CallError Apr 20, 2023
@niklasad1 niklasad1 added the breaking change Breaking change in the public APIs label Apr 20, 2023
@@ -382,6 +384,10 @@ impl<'a> Id<'a> {
}
}

fn invalid_params(e: impl ToString) -> ErrorObjectOwned {
ErrorObject::owned(ErrorCode::InvalidParams.code(), e.to_string(), None::<()>)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

strictly from the jsonrpc spec:

code     | message          | meaning
-32602  | Invalid params | Invalid method parameter(s).

we are using -32602 => message == e: impl ToString

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but it was like that before this PR as well, it's picking hair I'm fine having a slightly better error message than "Invalid Params" though we could modify it in another and add this extra data in the data field instead of the message.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't feel like a big deal (I'd expect people to match on the code), but having some more detailed thing inthe data field sounds more "correct" (would it be annoying for us to do this?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, just update some tests I can do it in this PR.

Co-authored-by: Alexandru Vasile <60601340+lexnv@users.noreply.github.com>
@@ -117,17 +119,17 @@ impl<'a> Params<'a> {
}

/// Attempt to parse all parameters as an array or map into type `T`.
pub fn parse<T>(&'a self) -> Result<T, CallError>
pub fn parse<T>(&'a self) -> Result<T, ErrorObjectOwned>
Copy link
Member Author

@niklasad1 niklasad1 Apr 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could have introduced type InvalidParams here but it is JSON-RPC error object it didn't make sense to have a separate type for that

Result::<_, Error>::Ok("ok")
.register_async_method::<Result<&str, MyAppError>, _, _>("should_ok_async", |_p, ctx| async move {
ctx.ok()?;
Ok("ok")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: maybe consistify these generic ones with what you did below with §Result::<_, MyAppError>::Ok(..)`

Comment on lines -282 to -290
impl CallError {
/// Create `CallError` from a generic error.
pub fn from_std_error<E>(err: E) -> Self
where
E: std::error::Error + Send + Sync + 'static,
{
CallError::Failed(err.into())
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok, so previously user errors were being turned into thie Failed variant, and now the user describes how to turn them into an ErrorObjectOwned basically? This makes a lot of sense to me; give users the ability to set the error code etc :)

Copy link
Member Author

@niklasad1 niklasad1 Apr 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this was a way to easily convert any StdError into a ErrorObject and let jsonrpsee pick the error code.

This was a bad idea it's better that folks take care of the error code etc explicitly.

Copy link
Collaborator

@jsdw jsdw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good and if I understand right, I like the extra control that users get here

@niklasad1 niklasad1 merged commit d6a9622 into master Apr 21, 2023
8 checks passed
@niklasad1 niklasad1 deleted the na-remove-call-error branch April 21, 2023 14:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Breaking change in the public APIs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

remove CallError
3 participants