Custom error details

[burdiyan]

The protocol spec for the error expression is closely tied to JavaScript's Error type, and is not very extensible with custom parameters. The spec says:

TODO: We should extend this to encode own properties that have been added to the error.

I wonder what are the plans for supporting the extensibility? Would it be defined as a separate expression type, or just an extension of the existing error message?

In my case, I'm experimenting with implementing the server side of Cap'n Web in a different language (Go), and JS-specific error types, besides feeling weird, are also quite limiting — no way to specify error codes, or custom attributes.

I was thinking the extra attributes in JSON and put them into the error message as a string, but it's ugly, and I don't like it.

Maybe one way to support the extensibility could be allowing to use string | object as message in the error expression? This should probably only be supported if type is a non-standard JS error type.

CC: @kentonv.

[kentonv]

The intent of the TODO is that if you have an Error object on which you've assigned additional properties, I want to serialize those properties. Like:

let e = new Error(msg);
e.shouldRetry = true;
throw e;

The shouldRetry property should be retained over the RPC boundary.

Sounds like that may be exactly what you need?

[burdiyan]

Right, that's exactly what I want. I was just wondering about how this was going to be serialized on the protocol level. So I assume either the current ["error", <error-type>, <message>, <stack>?] expression would have to be extended to support the custom parameters, or a new data type would need to be introduced, like ["custom-error", ...], or something else.

So, I was just wondering what was the plan in terms of how this is going to be implemented.