This course has been updated! We now recommend you take the Server-Side GraphQL in Node.js course.
Transcript from the "Errors in Resolvers" Lesson
>> Scott Moss: The other thing about inside of resolvers is that any errors that you have in here, so if I just come in, I throw an error,
>> Scott Moss: Your server will not crash. So in Express, if you put the rest API, if you just throw an error, your server is gonna crash, it's gonna die.
[00:00:16] That doesn't happen here, and that's because GraphQL wraps all your resolvers in a tri-catch. And if there's an error that's thrown, it catches it and sends it back to the client as an error. So any error that ever happens automatically gets sent back to the client as an error.
[00:00:32] So you don't have to worry about catching your errors in the resolver if you don't want to. I mean, there are still some scenarios where you would, like you don't want this error to go back. And instead, you wanna retry or if you're doing transactions or something like that.
[00:00:44] Yeah, you still might wanna do that but for the sake of like not breaking your server throwing error. You don't have to because these graph fill implementations catch it for you and send it back. Now, do you want that error being sent back to the client? Probably not, so that's where they allow you to format the errors that they catch.
[00:00:59] And you can say, I wanna format this error to get rid of the stack trace or rename it, or put a specific error code or something like that. So you might get into the habit of creating custom error classes that you create yourself. So when an error happens, you'll throw that custom error class.
[00:01:14] And then your error formatter knows what to do when it sees that custom error class being thrown, and so forth. So it can get pretty advanced with the error handling stuff there.