trpc.error
syntax
#270
colinhacks
started this conversation in
General
Replies: 4 comments
-
No big opposition here, kinda just mimicking how it is to throw unauth errors etc in graphql servers |
Beta Was this translation helpful? Give feedback.
0 replies
-
I can submit a PR. Which solution do you prefer?
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Sooo, actually - - Thought more about this and remembered why it's not like that. I don't think the errors we throw in the router should be tied to http, they aren't now and I use a error.code (taken straight from graphql, I have info in the docs) which is translated to http codes in http middlewares. I am planning to do support for other transports later so internal codes should be something different from http. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I see the appeal of the
trpc.httpError.forbidden
syntax for common HTTP codes, but I think there should be a fallback function for easily throwing HTTPErrors with any numerical code. Similar to the v0.x syntax:trpc.error(code: number, opts; { status?: string; message?: string; originalError?: Error })
I'm used to thinking about HTTP codes as numbers. It looks like you're trying to require a string representation of the status code (
TCode
) which is understandable. You could use something like this to convert the numerical code into a string code: https://github.com/prettymuchbryce/http-status-codes/blob/master/src/status-codes.tsAlternatively, just expand
trpc.httpError
to include all possible status codes. It's odd that only certain codes are available.Beta Was this translation helpful? Give feedback.
All reactions