Type safety of throw errors

[jokull]

I'm really interested to see how throwing errors can be made type safe.

in TypeScript type safe errors usually means you sacrifice throw and instead have some kind of Result type and handling with a library like neverthrow.

[unnoq]

Just posted an MVP version on X: https://x.com/unnoqcom/status/1901433349723537690/photo/1 . The main idea is that you define the types of errors you'll throw separately. Thankfully, this approach seems to work perfectly for oRPC!

[unnoq]

Hey @jokull does it is thing you looking for?

[jokull]

It's nice, but I'm wondering if there is a way to avoid passing around the constructed error map?

Context will have an instance of ORPCErrorConstructorMap called error, but if the handler calls out and you need to be able to throw the error somewhere outside the handler:

a) how would I create the type signature for the error map?
b) is there a way to avoid passing it around and being able to throw from the map?

Also, the error type signature is Error | null - but shouldn't it be unknown | null since I can throw not just Error instances?

Just some thoughts - nice work :)

[unnoq]

a) Just throw normal ORPCError we take care the rest: https://orpc.unnoq.com/docs/error-handling#combining-both-approaches

b) This is recommendation but you can config it here: https://orpc.unnoq.com/docs/best-practices/no-throw-literal#configuration

[jokull]

The error data for new ORPCError errors won't be type safe though.

I see now that you can access the map (route["~orpc"].errorMap) so the error map wouldn't strictly need to be passed from handler code to internals. Not sure I would use that however as it couples internals to the handlers. With throw you get much deeper control of code flow, and it does seem to work, to an extent, but full type safety is tricky.

I see error maps as a way to communicate a whitelist of errors the client might want to attempt to handle elegantly - but not a promise that other errors won't be thrown (with how JavaScript works this is an acceptable constraint!). I think I understand the limitations now, and I do like the design you have with safe() and isDefined.

[unnoq]

I'm missing somthing in b) here how you create errors from map: https://github.com/unnoq/orpc/blob/main/packages/server/src/error.ts#L19