Full Stack Error Handling Type Safety (Either VS Errors)

[danielyogel]

Was wondering, if anyone uses an Either type (together with always 200 status code) - instead of throwing - in order to achieve error handling type safety in the client?
Any reason why this may be a bad idea?

[KATT]

I've gone back-and-forth on this over the last few years. At the moment I prefer treating errors as exceptions.

You can return an Either but be aware that it'd also return a 200 response [and subsequently get cached if you have cache enabled] unless you do some custom stuff in the responseMeta.

Furthermore - you can do explicit error formatting in tRPC - not sure if you've played with formatError yet.

[KATT]

Have a look at the tests for a deeper dive into formatError

[KATT]

Might be worth shooting the question out on the discord too - https://trpc.io/discord

[danielyogel]

Thanks!
The only client example I see, is using hooks in the client, but I use a vanilla client - so should I use something like 'waitError' (as used in the tests) to infer the error types in the client?

[KATT]

I see! The error formatting happens in @trpc/client so it's not an issue, but then I also understand why you want an Either.

You could do something like this 0379dbf - there's definitely ways of making this more generic so you could have a safe wrapper but I'll leave that to you to figure out :)

[KATT]

Actually - I took the demo a bit further, see here: #1188