Custom Error classes

[joostn]

Is it possible to define custom error classes and throw them over the wire?

Take your authentication example:

let batch = newHttpBatchRpcSession("https://example.com/api");
let sessionPromise = batch.authenticate(apiKey);
let name = await sessionPromise.whoami();

authenticate() could throw an AuthenticationFailedError, and the client can catch this to show a login form.

Currently it doesn't work, the client receives a generic Error object. The docs confirm this: only "Error and its well-known subclasses are passed as-is"

[kentonv]

In general, we intentionally do not support custom pass-by-value types. All custom types must be pass-by-reference. This includes custom Error subclasses.

The reason for this is because custom serializable types have proven to be a security disaster in Java and other languages. It's just too easy to create a custom serializable type which inadvertently allows an attacker to trick the remote party into doing unsafe things, by sending an instance of that type when it isn't expected.

What we can do, though, is:

• Override error.name to match the custom type ("AuthenticationFailedError") even if the class becomes just Error.
• Serialize any additional own properties placed on the error object, so you can communicate additional details via properties.

I had intended to do both of these things but it looks like it's still marked as a TODO in the code.

With all that said, I would probably recommend having authenticate() return null on failure, or something like that. It's a style preference but I generally recommend throwing exceptions only for unexpected problems for which there's nothing you can do -- not for situations where you want the client to take a specific action, like redirecting to a login page.

[joostn]

I like to use an exception in this example, we're not awaiting authenticate() so we don't get to see its result until after whoami (which would either have to throw, or also return an error object).

Another example would be a resource that's temporarily unavailable. The client could decide to retry after a while. Instead of throwing, I could explicitly return an error result from each function, but in a pipelined series of operations I don't see how I could handle this without awaiting each intermediate result.

I managed to work around the limitation by throwing a non-error object over the wire, and wrapping my calls in a catch/retrow to convert back to the original error class. This works, so it's not a big deal, but it's not as clean as I would like.

Thanks for your reply. This is great work, I really like it and I saw it just in time for my current project!

[kentonv]

You could have authenticate() return null, and still pipeline on it. The pipelined call will throw an exception, since you're calling a method on null. So either way, you end up with an error. But meanwhile you can also await authenticate() itself. If it returns null, then you set a flag saying "authenticate failed, ignore errors". And then immediately after that all the chained calls will throw, but you could catch the errors and, if the flag is set, ignore them.

I'm not saying this is necessarily better, though! Just pointing out it is a thing you can do.

[joostn]

Yes I see what you mean. Thanks for replying!