Investigate ways to improve rpc error handling

[ganemone]

The current process for failing an RPC is to return a Promise that rejects. This works fairly well, however it falls a bit short when you want to serialize data with the RPC failure.

It is generally good practice to only instances of an Error object to Promise.reject(), and similarly to only throw Error objects (see https://eslint.org/docs/rules/prefer-promise-reject-errors and https://eslint.org/docs/rules/no-throw-literal). However, lets say you want to signal an RPC failure, and you want to serialize some JSON down to the client. We currently only send the error.message data to the client, meaning you are very restricted in how you handle errors.

Node has somewhat recently standardized on using Error.code to signal the type of error (see https://nodejs.org/api/errors.html#errors_error_code). A good first step would be supporting this property on the rejected error.

If error.code is not enough (which I suspect it won't be), we could support serializing arbitrary JSON on the error.meta key.

Thoughts?

[AlexMSmithCA]

This sounds reasonable to me. To make sure I understand, is the proposal for error.meta to contain an arbitrary payload that contains additional context for the error? Or is it for supporting non-standard error codes?

In either case, I agree error.message isn't great for robustly handling errors.

[ganemone]

Basically we will serialize error.message, error.code and error.meta from the server to the browser so that you can use it in your application