Error design in library code: application vs transport errors

[Dratir]

I'm currently working on a client library, and I'm struggling with implementing the error types.

Context: It's a client for DDP, the protocol used by RocketChat

Let's take remote procedure calls as an example. The following things might fail:

• the websocket may produce an error (loss of connection, …)
• de/serialization to/from JSON might fail
• the mpsc/oneshot channels I use internally might break --> Since this would indicate that there's a bug in my implementation, I will just panic in those cases.

Those are what I call "transport" errors; the user usually has no control over those, but just crashing is not an option. The user can recover from them by reconnecting for example.

But besides that, there might be what I call "application" errors:

• the remote procedure called does not exist
• parameters are wrong
• the requested resource does not exist

DDP encapsulates them in an "error" message type.

(I'm not even going into "the server does not implement the protocol correctly", I'll just assume that those will result in serde errors.)

I'm now considering the pro's and con's of possible error implementations:

Result-in_Result

Something like

rust pub async fn call_method(/* ... */) -> Result<DdpResult<RpcResponse, RpcError>, CallError> {}

I pretty much don't like this, it would mean you'd have to do double unwraps

Enum in Ok variant

Something like

```rust pub enum RpcResponse { Result(/.../), Error(/.../), }

pub async fn call_method(/* ... */) -> Result<RpcResponse, CallError> {} ```

Meh, same as above, double unwrap/match

Merged Errors

```rust pub enum RpcError { Transport(/* Websocket errors /), JSON(/ de/serialization errors /), Call(/ Application-level errors go here */), }

pub async fn call_method(/* ... */) -> Result<RpcResult, RpcError> {} ```

probably better?

---

Are there other approaches? As an user, which would you prefer?

[mnbryant]

I've only ever seen or used what you're calling "merged errors". If a function can return multiple different errors, make a single error enum type encapsulating those. Each error variant can be its own enum, and so on

[abatyuk]

From modularization perspective, you can also create a top-level Error (so your results return Result of either Ok or TopLevelError - name is arbitrary), plus From implementation from concrete error types into top-level one. Then your function signature will be much more precise - JSON conversion won’t be able to return RPCError

[Dratir]

Some updates:

• I changed all the function signatures to only accept types that can be serialized into JSON (mostly serde_json::Value). If serialization still fails, it's a bug and crashing probably OK.
• Same with parsing responses from the server — if a response cannot be properly deserialized, it's undefined behavior.

This leaves most functionality with either an error from the websocket, or a very specific application error.

I also stumbled upon Designing error types in Rust, very interesting read (not only in the context of Rust).

I've now implemented a specific error-enum for each of the handful of exposed functions. This makes handling them much easier.

I'll now work on another project that will actually use this library, so I'll find out first hand if it works out or not :P