Error Handling

[00:00:00]
>> So this part is gonna be on error handling and testing, which I think is very important if you're gonna be an advanced GraphQL server developer. You need to know how handle errors. So we've talked about it, we've thrown errors in here, we've done so many things. And if you've ever worked on a server before, especially know that if you throw an error, the server breaks.

[00:00:17]
But if you notice, we've been throwing errors like crazy and nothing's broken. It continues to work just fine. So something's happening, and we didn't do anything about it. So I'm going to explain to you what's actually happening. But basically throw your errors, they will be caught. And that's because GraphQL and not Apollo, but the actual GraphQL spec inside the resolvers and as the framework is or the GraphQL is initializing in the context of GraphQL, any error that is thrown is automatically caught.

[00:00:47]
And that error is gonna be sent down through the query. So you're still gonna get back, most likely at 200 unless you change it. And instead of getting back a data property, you're gonna get back an error's property, which can be an array of errors that have everything on it from the message of the error all the way down to the stack trace by default.

[00:01:07]
And that's what GraphQL's got to do. So to demonstrate that, what we can do is let me stop this thing. And I'm gonna go to this example one that I have here, let's just make a new field on a user. And we'll just call it error. And it's just gonna return, it's supposed to return a string.

[00:01:31]
Let's see that. But instead, what I'm gonna do is I'm gonna go to a user, oops. And I'm gonna make a resolver for that error field and I was gonna throw an error. Like that, so I'll start this up, node server, like that. And then I'll try to go get a user error field.

[00:02:15]
So, if I say give me, and then give me the error field like this, you can see I get back this errors array and data is null. So if it wasn't an error, data would be the objects and some stuff and errors would probably be null. So let's inspect this and figure out what's going on.

[00:02:31]
So errors has a couple things. One, it's an array. So that tells you you might have many errors happening. And it really depends on your implementation and what you wanna do. But this is where it's got to go, and this is GraphQL spec, this is not something that Apollo's doing.

[00:02:45]
By default, you're gonna get something like a message. So that's probably, and if you're ever using error in JavaScript, all errors have a message, it's usually whatever you type into the constructor. Like I typed in no, so message showed up. Locations are exactly what they sound like. The line numbers and the columns that those error's happening according to that resolver.

[00:03:07]
The path is the path to the resolver. So you can see, I issued a query on the me field and then that returned a user type and then I got the error field from there. So it's showing me the path to where the error happened. And this extensions thing is something that frameworks like Apollo and I think GraphQL does a lot of this stuff by default too.

[00:03:28]
It takes advantage of to allow you more metadata on the error itself. So right now by default, we're getting an error code right now saying internal server error. And then we get an exception which has an array of stack traces. So it can be pretty detailed. Now you might be asking yourself, you don't want to show the stack trace to your client.

[00:03:48]
This is kind of crazy. I don't know about that. No worries, if you put your app in production mode, Apollo gets rid of the stack trace for you, so you don't have to do it. Even then, you can also modify it yourself with a method that I'm gonna show you how to do.

[00:04:02]
But this is a perfect place for you to basically, instead of looking at status quos to figure out what's going over your server. Instead, you will look at these extensions and look at the codes. You will have deterministic codes that happened depending on what error happened on your server, and your client can respond to those codes.

[00:04:24]
You can also put other extensions in here like a message to show in the UI. So maybe the server even comes up that message. So the client doesn't to figure out like, what do I need to tell the user when this error happens? So the server can tell you this is what you need to tell the user.

[00:04:38]
So you don't have to do anything. The whole purpose is to offload all that stuff to the server and have GraphQL take care of it. So the client can just take it and render it on the page. You shouldn't have to do anything on the client side. Although you can if you want to, but you have the ability to handle it all here.

[00:04:52]
So again, that's any error that you throw or any error that is not caught. Any exception that's thrown is gonna be automatically caught and it's gonna show up here. And your server is gonna keep running. It's gonna keep running. So that may be a little different. Cuz I know a lot of work goes into keeping your server running when you have errors, especially with node.

[00:05:12]
Well now, it's just gonna run unless it breaks completely outside of GraphQL in a middleware somewhere or something like that database connection. It's always gonna keep going as far as errors are concerned.