feat: customizable JSON-RPC error codes via new enum variant on CallErrror

[niklasad1]

The motivation behind this change is that we need to provide functionality for users to configure their own error messages; that means error code, error message and data, https://www.jsonrpc.org/specification#error-object

Superseeds #393

Closes #299

[niklasad1]

might be annoying serde_json::RawValue here but at least we rexport it from types

[dvdplm]

cc @maciejhirsz Thoughts on this?
For context: it seems like substrate only adheres to the spec (which mandates a full "Error Object") some of the time? Possibly because it's verbose and annoying.

[niklasad1]

cc @maciejhirsz Thoughts on this?
For context: it seems like substrate only adheres to the spec (which mandates a full "Error Object") some of the time? Possibly because it's verbose and annoying.

example of this can be found here for context but I think these error codes is still quite useful in the context of substrate so we should really support it.

But I was thinking of two variants of register_method:

1. like old one, just require StdError + Send + Sync and just let jsonrpsee assign the error code
2. register_method_with_custom_error, require the error to impl RpcErrorTrait

[maciejhirsz]

This looks good to me, but I'm wondering if trait is the right approach. I think it might be better to have an enum like:

enum JsonRpcError {
    User(Box<dyn std::error::Error>),
    ParseError,
    InvalidError,
    // ...
}

With a From<Box<dyn std::error::Error>> impl, so we can auto cast all user errors into the User variant and give it some default error code, while also having the option to set codes for things like params parsing fail etc.

[niklasad1]

With a From<Box<dyn std::error::Error>> impl, so we can auto cast all user errors into the User variant and give it some default error code, while also having the option to set codes for things like params parsing fail etc.

Right, that would be nice but the custom error messages won't work but if we could do:

enum JsonRpcError {
    // provide default error code
    User(Box<dyn std::error::Error>),
    // user provides error code and similar
    CustomUser { code: i32, message: String, data: JsonValue },
    // some specific error code
    ParseError,
    // some specific error code
    InvalidError,
    // ...
}

that would be quite flexible and better, what do you think @maciejhirsz? :)

[maciejhirsz]

Ye, that works I think.

[niklasad1]

we might want to put non_exhaustive on this but a little weird to just add some error code for non defined enum variant :P

[niklasad1]

this might save allocations of the value is already a String

[dvdplm]

This should work.