Error handling best practices

Hello 👋 First of all thank you so much for this amazing project, it’s awesome to use and we’re adopting it for some of our public facing services as an alternative to GraphQL at utility-company scale

Question about error handling best practices; the JSON-RPC spec includes the following description:

The error codes from and including -32768 to -32000 are reserved for pre-defined errors. Any code within this range, but not defined explicitly below is reserved for future use. The error codes are nearly the same as those suggested for XML-RPC at the following url: http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php

The remainder of the space is available for application defined errors.

https://www.jsonrpc.org/specification#error_object

However, TRPC errors appear limited to the subset defined in the spec:

Does this mean that best practices for error handling is to return them as a standard result of the request instead of as a special error thrown:

// I.e. this
return { error: "CUSTOM_ERROR" }; // This would also now be typed correctly on the client
// Instead of this
throw new TRPCError({ code: "CUSTOM_ERROR" }); // This is a type error

Once again, thank you so much for this amazing library!

[KATT]

Again, check out https://trpc.io/docs/error-formatting

It might be what you are looking for.

[sam3d]

I considered doing that but yeah exactly I didn’t want to lose implicit type safety. I’ll continue to see if I can wrap mutateAsync to return { data, errors } and also add an options object with something like axios’s validateStatus. Thank you for your help (and again for making this awesome library!) ❤️