Formatting & Error Codes

[00:00:00]
>> We broke some things. I'm gonna dive a little more in detail about how to actually format some of those errors. And then we're gonna talk about some of the built in error classes that Apollo gives us, that has like very specific error codes. So let's do that.

[00:00:14]
So I just showed you how to throw errors which, it's not that hard. You just, throw an error. That's really cool. But what if we wanted to use some custom errors like for instance, a user was not authenticated. We could handle it like we have authentication logic in our context, method and our other server and right now.

[00:00:37]
We're just throwing errors. They're super generic. But what if we wanna make our own error class that had like a some specific code. Well, Apollo server has some of those built in. And one of them is called authentication error. That's a one. Another one is, user input error.

[00:00:52]
And I think they're all based off on Apollo error. So you can make your own era class extended from Apollo era and use them for wherever you want. So in this case authentication error. If I wanted to say that user was authenticated, I'm just going to replace it here.

[00:01:10]
Authentication error. And we can just say, not off like that. Save that. There we go. Try to run this again and you can see I still get the same message not off everything but then you get this code. The code is changed. It's unauthenticated, we didn't have to do anything about that.

[00:01:36]
You can see the statue starts off with authentication error, and we still get this stacktrace. So this is like a really great starting place to create or to use, like some built in error messages or error handlers that a GraphQL or Apollo provides for us. Another one is like the user input one.

[00:01:53]
So this is like one if I think we had a question earlier, what the wrapping the resolvers be a good place for checking the input on an incoming resolver. Yeah, and then if you want to throw an error based on that you can use this class right here user input error.

[00:02:07]
So you gave me the wrong field or something like that. This will give you a nice area that you can handle on your front end to determine if the user input was messed up or not. So you can show an error to your users like, Hey, you just you didn't type the right stuff.

[00:02:22]
And it's a little off. And usually it's something that like you can't detect on the schema level. So, yeah, the schema says it's a string, and you sent me a string, but my database says it can't be longer than eight. And you sent me 10 characters. So I'm gonna throw you a bad user input error.

[00:02:37]
So something like that, and you can see is pretty, pretty simple. There's nothing to it. And as far as like extending your own, I mean, you can look at the docs but it's basically super simple. All you have to do is extend this Apollo error. You can add your own message, you can add your own code, as it's very basic, but you can also just make your own error class.

[00:02:58]
And it also works pretty fine to just give it a code. It's really basic if you go look at the code for Apollo error. So that's one thing for the built in errors. The other thing is intercepting errors and changing them. So you can go down to Apollo Server.

[00:03:15]
You can type in formatError(), which is a function. And you can see that the arguments here are gonna be basically the error that comes in from GraphQL. So if we do this, and I were to just log this error here? You'll see what I'm talking about, console.log(e), and I'm just gonna return that error, so we don't break anything.

[00:03:42]
Run this one more time, still breaks. And if we go back, we can see we get this error here. It's a GraphQL error. Wrong filters the message that I put and you can see, here's all the stuff you have access to all this so you can remove Pushpop.

[00:03:57]
Do whatever you want to this error and return it. So if I'm just like, you know what, I don't want to have the exception on the extensions very quick. So I'm just got to take that off. You could just take it off as an object, you can modify it and return it however you want.

[00:04:13]
There's nothing stopping me from returning a completely new error here. And says my error. And completely overriding whatever you through in your resolvers. It's my error now. So you have complete control over that. This is also a good place if you're using something like Century or any error reporting software, you would do that here.

[00:04:38]
It's okay, I wanna report like actual app errors. I don't wanna report user input errors. I don't wanna report authentication errors. So you would filter based software errors type to determine. This is something you wanna report to Century or not. First is reporting every single answer, every single error to century or whatever your error log in services if you have one.

[00:05:03]
That's something we do a lot because the last thing I wanna do is log into error reporting software and see like a 1000 unauthenticated errors that's not a real error. I don't really care about that I used to forget the Azure API key. But I do want to see if my app crashed because the resolvers messed up or the database hung on a query or something like that I want to see those errors.

[00:05:23]
So I'll filter them out here and report only on that. And it's pretty easy. So if any one of those errors were created with Apollo you can do like instance of Sydney like he instance of and it feels authentication arrogance is an instance of authentication error is it an instance of.

[00:05:38]
Whatever that works pretty well, even an instance of Apollo era works pretty well, they all kind of come from there. Or you can just like look at any other type of metadata that you want to look at, but you have complete control over it. So if you can't get the type of error reporting you want by creating an error class, you can always go back to format and do literally whatever you want.

[00:05:58]
And that's what's gonna happen.