REST API Error Handling
Curious if there is a standard best practice for laying out error handling on a simple rest api. How do you handle the error message on the frontend (does that come from the error response?). What is the general structure of using zod to check body shape and then all other error handling (nested try catches?) do u use safeParse on zod?
I am trying to really clean up my code with full error handling and want to know what the best option is for it. Always been a minor point of confusion for me somehow.
(Should I basically wrap the entire endpoint in a try catch and then nest more inside of it for specific errors? Should error messages come from the response or should it be a code and the frontend chooses the message, or something else??)
16 Replies
All of the above with prisma and zod *
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
@lee no
Just nextjs api
For server-client communication, stick to the http standard
In the front end you can do whatever you want
Re: safe parse in Zod: it depends! Do you want to throw an error or not? I personally like the pattern of sticking zod checks in a try catch block but it really doesn’t make much of a difference
Worrying about “best practices” too much early on is kind of a waste of time imo
@cje Ok cool thank you, I am not too early on actually. Trying to clean up my code base.
main functionality is done, just not clean error handling, with some cmpletely missing
The nice thing about Zod is that usually all your zod errors will be the same http error type
What I try to do is get to a point where inside the actual route handler I’m mostly just sending 500s
Auth, bad request, etc has been handled before even getting there
So will you try to catch all ur errors or just send them out when u find them
I have a try catch in my entire route handler
and that outermost catch will just send back a response saying an unknown server error has occurred, since I will have nested try catches that will handle the more specific stuff
not sure if thats a common idea
I don’t usually do that
You know which parts can and can’t throw
So handle them accordingly
Oh true
so around prisma stuff, zod stuff, anything else I make custom that throws
Even stuff that could throw with the wrong input
You know it won’t because you’ve already used zod
But it’s difficult to give specific advice
@cje Yeah I get that, kinda hard to give general advice here
appreciate ur help regardless, think I got a better idea now
@cje So here is zod pattern I am going with
and if we get past this try catch, we know body is valid
that looks good 🙂 i'd probably define the schema outside of the route handler, but if you're deploying to serverless where it will be created from scratch on most requests anyway it won't really make a difference.
if you want to get really fancy (and have a good reason to use the next.js backend without trpc), here's a pattern i came up with a while ago using
next-connect and a curried function that will validate for any schema
https://github.com/c-ehrlich/anket/blob/main/pages/api/question/index.ts
https://github.com/c-ehrlich/anket/blob/main/backend/middleware/validateResource.middleware.ts
it makes the next.js backend feel a bit more like expressOh thats pretty cool, I probably should have just gone with trpc from the start but when I started this project I didn't know any of the t3 stack so thought it would be too much to even make progress. Maybe I will migrate to it one day.
Im still a bit lost on if I am doing it "correctly" but this is my setup atm and an example using a POST request. I think I have some more fixing up to do tomorrow because the Errors are not being sent back for some reason.
I have a feeling using one try catch for all those different operations might not be smart