Handling and Throwing Errors

additional the the the catch has happened or the catch has not been triggered, but this will then always run no matter what after error. Of if it was successful or not. That can be really handy for, like, teardown. You wanna remove event listeners or Yes. Regardless of of what happened. Sometimes, like, you may ex something might will have an error, and then wrapping I'm actually excited about having that.

and you have a function that you don't necessarily know if it is you can you can go into the network tab and look at the HTML that was returned, and it will show you what actually happened in that case. Yeah. That's an easy one to to have memorized if that's happening.

go ahead and use them,

is less important. But when they when they're contextual information and instant feedback to the user. Right? Where, like, if if I

back in the olden days before Mhmm. React and whatnot, we had this idea of, like, flash messages, which you would just then and then you can see, okay. It happened in my code. You know, the stuff that I can control, Throwing errors. Let's talk about it. So you when you're writing

the the error could take place on line one character, you know, 2,000,000

writing logic and you say, I don't necessarily care how this error is handle handled because I am simply for any possible uncut errors. So inside of each of my API routes, I may want to handle that in that specific API route. But if I don't,

without typing a new instructing a new instance. And and even if there there's some,

Alright. Well, we'll talk real quick about Node about TypeScript errors or errors in TypeScript, not necessarily, like like the the errors when you hover over top of something that is broken in TypeScript. But when you are catching your errors in TypeScript and you want to

you know, thought there too if if you're catching an error that exists and then just throwing that same error. If you're not modifying it all, you just throw the error without even creating a new error, but we'll get to that in a minute. So inside of this this urgent care for a cut finger this morning, but, hey, man.

what function called what function, what called what function, and it will show you which files and line numbers they were actually is is kind of a tricky thing. So we're gonna we're gonna dive on into it and try to explain all of those pieces. My name is Wes Bos, developer from Node. With me, as always, is Scott. How are you doing today, Scott? or

Otherwise, it's best to follow best practices.

and those should not be actually displayed to your end user.

promise or not or if you simply just want to maintain the same syntax for everything, an error happened on the server. Your client code is assuming that JSON is coming back, but it it's not because it's it's setting some HTML back. And often, error. Like, a a very common one would be

give your users are like, email exists, wrong password, or something to indicate if the user actually has an account there.

the reasoning for that is that, like, they're saying that the the response from GraphQL as well off of, just a a normal promise. But Feeling feeling like this is just my life. That's just how it goes. I gotta chill out, I think.

this runs after a successful

where it went wrong, and it will show you essentially thing. You may have stack traces in there that that are are sensitive. You may have, like, an actual error message that is sensitive, You may want to catch errors at different levels depending on what it is you're doing. Especially a client side, you you may be thinking about, I wanna catch these out of UI level where I can display them. Right? You may have, function kinda fake it into a promise with by wrapping it in a promise dot try. Yeah.

obviously, I think you should be able to solve a lot of your problems Yes. That that's always funny. Like, successfully errored, many instances where I assumed something would be of a specific type because I can't imagine specific words about

generally in Century ESLint is in open beta.

Something went wrong. You simply throw it. This didn't work. You throw it out there, and then somewhere else in your application, and then then help you from there.

from using those errors to know what what is actually happening.

be called the moment that an error has happened. So, typically,

and I sure hope that we have it.

And, as we've mentioned already, it's common to have a lookup

there's no, like, structure to how to handle them. It's just a bit of a mishmash, implement your own logic there as to to how to display that. Yeah.

We should also say there's, like, kind of, like,

it's being stored. And there's a lot of other services that do logging, whether it's like paper trail or any of these things. And they just basically say, if your console logging or console airing anything, I'm just gonna collect all those logs, and I'm gonna give you an interface to be able to find and search for if I submitted my password

something went wrong in that validation,

a library method or function and then create a new error based on something that you, GraphQL will return a status code of 200

So often, what you'll have to do is you'll have to, like,

And my game crashed last night, and I was just like, alright. They're gonna be they're gonna fix this. Whatever this is, they'll fix it,

sometimes, though, they're trying to protect and and read the stack trace, doing some validation or doing a database lookup.

and then the error that comes in from the catch. So you don't have to create a new one.

and we'll say, like, password cannot be created. And that's really frustrating because you have no idea

you know, try again or something. Right?

is I'll check the accept header on the Wes. And if the request is asking for JSON, you would throw a flash message on the session. And then the next time a page loaded, that error would show up, and that was really helpful for, like, your password has been reset successfully two

Yeah. I do like that that visual of throwing a ball because it is just like, I got a problem over here. Sad. Yes. Yeah. Now you're gonna have a problem

Data boundaries. Yeah. This is the idea that in your UI, you can write a error boundary

contextual

where they may be useful, form submission,

man, it would not let me create an account. It was like, These types of things could get thrown inside of your application.

This is something that many And if you if you know, it's it's half of these are gonna fail anyways, it can be helpful just to stick that final logic in your finally

because we always see the try catch. But there's also both there's also a finally too. So there's a finally block you can do after the catch or a dot finally

and then throw it into a queue to to retry at a different point.

class instance, inside of this bundle here

error to it. Or even even further believe me, I've hit or I didn't I didn't account for that possibly being an issue. Right? It just

Yeah. I I personally

this error and this log are related to each other. This explicit one. You can you can when an error happened to a specific user

but not like account already exists because that is a security issue.

JSON or whatever format, like a React Vercel component payload that that you're looking for.

would rather handle in a specific way. Like, for instance, like, insert failed or something like that rather than something that has more context.

logging it or being able to fix it in the back end without exposing that to the client. So something very important to keep in mind. At JSON API, this is something that I've done quite a bit Wes I will, like, wrap I like that flow a lot. It makes a lot of it makes too much sense, honestly, to be able to have your error and everything at the same level. There there's also something that's not explicitly related to errors, but I feel like I should mention it because I don't know if a lot of people end up actually using this,

either in, like, a Node module or in a a a module library, or it's gonna show you that it, like, happened, like, deep within the internals of v eight or Node. Js, which is not that helpful. But if you can sort of back it up Vercel levels sometimes your stack trace is going to be is gonna show you that the error went wrong

that will then or an error. So, basically,

bad people sorry. I I can't delete that item because you don't have have access to it. Now those have been replaced mostly with Toast errors, error message that gets displayed to the user, which is so frustrating to get. Yeah. Error messages you do not want to, into a string, but the message itself can be it it Sanity be several types. Right? You could you can throw an object in there as as well. If you are creating a custom error, so you use a class, especially with, like, library code, I don't necessarily know how,

But in in production code, errors just be happening, and you might not know about it, because you might not encounter every use case in development. So the fact that things could be happening without you knowing a sometimes

and then not both.

and, like, logging

some kind of error on their side. Oh, that's that's a really frustrating part is that the what might have happened there is that the their server code you need to check for the type of it. You need to do a little bit of narrowing. Maybe you'll have a type predicate

Yes. Totally.

this to be a situation

a analytics Vercel service. Right? There's there's a high probability that the user will have an ad blocker on, and that fetch or that that post request is going to fail.

that will try and catch anything that that bubbles up.

errors specifically

you need to be able to translate that, like, obtuse error that they got to actually help them out. So that's why sometimes you'll get, like, a reference, like, a hex value or something weird in there or a unique value where they can just go ahead and look up what actually happened so that you know it's that asynchronous

I'm I'm curious, like you said, strategies, all that kind of stuff. So leave a comment below,

what there is, which is sometimes very frustrating inside of TypeScript. But email SMTP But then you also if somebody were to email you that that is legitimate, fathom why it would ever look like that. But Mhmm.

if you're trying to report some data to you often have to, like, translate them because you don't necessarily wanna send,

If you do need to add additional context, then it makes sense the error from,

a

system packages.

cause property to your error. And what that will do is Like, for example, a unique constraint on a database.

in a try catch because that allows you to say, like, alright. In this block of code, I I got my hands up ready to Yeah. Ready to catch it in case this thing, starts throwing. So and then you can handle that how how you may. Exact and the other benefit of a try catch block is that you can put you can put a lot of logic inside of a try,

One more thing is is when you're throwing an error or or when errors are thrown, generally, the message is going to be a string or it's going to be something that can be parsed client errors, it both of them

was success successfully took place, but that response was that there was a problem somewhere.

If you're trying to save, like, an account and that email is already existing in the database, there's no nice way to do it, and and the UI is all all gunked up.

that will first check if it is an instance of an error or instance of your custom error. And then once you have that, you'll be able to then go ahead and work with it, you know, display a specific message or Mean that if you're if you're catching it and simply throwing it again, Yeah. And there's many cases in your logic where some errors Yarn then you may wanna just catch that

I would not know what would happen if you were using a Toast message because they're usually ephemeral. Well, that happens to me a lot. Yeah. Or it it goes away, and I I wasn't looking or, like, I said, it falls on the screen. Yeah. Yeah. That drives me nuts. Drives me nuts. So in those types of instances, it makes way more sense to put that in line contextually.

the word that we use there is is catch. So simply like it's Scott has here, it's like throwing a ball, but it makes you sad.

it will not gum up your stack trace.

write code

you want to wrap your code,

sometimes it makes more sense to just handle it right away inside of your application.

There's a message. That message is the message that was written when the error was thrown. So you could think of this being like, logging and, being able to solve these errors is something that you'll want to do in production specifically of the response codes is something that is a foundational skill that you'll need to have. But in general, you know, the ones related to errors,

writing a bunch of, like, promise based code where you don't think an error should happen. I'll I'll tell you that because synchronous function that is not returning a promise,

you know, logging software like Century or something to handle that, like like, actually give you the insight to that information. But the application might not the rest of the application might not need to know about the exact specific cause.

Or, like yeah. You you don't wanna give, people anything that they could then use to turn that information

your you don't want your navigation to break if something, like, small happens on on your website. You don't want the whole website to break. So you'll often have several levels of error boundaries

React has it.

you know, error handlers or, and and I'll move on from this crash, but they got that crash. I I'm very confident they got that crash.

regardless of what happens, I'm gonna display this to the user.

where AI can actually really help you. Because sometimes

the UI where where it's happening.

is a few things. There's a name. The default is capital e error.

So, like, because it's not working. And you might be using it yourself and be like, it's working for me. Next thing you know, you you're like, oh, wait. I have a special flag on my account specifically, or I have some logic that targets my my account specifically or not another users or whatever. There's there's some mismatch there. So being able to over there, and and how will you handle it,

or cannot parse server errors into handle

is Yep. Is the most important, and it makes it makes fixing these things way easier. Because let's say a a bug showed up 100 times in a specific version of your app and somehow got fixed without you even knowing it, you would be able to see, oh, this isn't something I need to investigate right now. They also just, like, today announced

your logic in

like code.

in that case. Or in in some cases, what's happening, and maybe I'll talk about this right now, is that

Yeah. You have no idea. In fact, I do I was playing a game, Clair Obscure Expedition 33. Fantastic game. I've been playing it for a bit, and, like yeah. The the helpful messages for authentication

Wes, do you wanna explain what the stack is? Yeah. The stack is a stack trace leading up sort of a treasure trail for

that,

translated into multiple languages as well. But then if there is something that pops up that is not expected, you'll often fall back to, like, a a very generic the errors are unknown by default. Meaning that before you go ahead and use them,

you know, you get all the it says, here's the things you gotta do. Got I I got all the check Bos. All the check boxes are green. I use one password to generate a password. I click go, and it says the error message pops up, and it's just password is not valid. What do you mean my password? I I could not be more valid. And I tried these several different ways, could not get past it. I'm sure it was probably

how to handle them, how to throw them, what what they contain.

logging

Yeah. Yeah. You don't need the new keyword when you Yarn throwing. So if you're simply just throwing a new error, you can you can just throw error.

because it it makes so much sense to log and store these errors, and it's only gotten better. So they handle

like I said, you can do you can do whatever you want with the errors, but you gotta first check

There's syscall, path, Wes. These are types of things that you may see frequently in Node apps if you're working with FS or any of the, given Node, So that way Wes your user looks at it, it shows you. I had an issue.

in line error the other day, Wes, on a just one of those cheap smart home apps.

a helpful way. If you've ever, like, had an error on a website and you look in your dev tools and it says Sanity read angle bracket JS doc, you can, but you cannot say this function throws

and we're using a lot of the language like catch. And and so, typically, one of the ways that you're interacting with errors is via promises in your app, whether that is before this podcast was presented by Century, like,

in TypeScript, meaning that you cannot say, I've I've had my course platform crash several times where there was simple things where I just expected saved it's a function that wraps your promises and will return to you a tuple, meaning an array of two pieces of data, the first piece being an error, the second piece being the actual data.

Our application is full of of errors. I I I write a lot of errors myself

Is I genuinely think this is cool. They can attach it directly to your spans and errors to be like, contextually,

or not. So if you're chaining a whole bunch of stuff and somewhere in that chain, you have a, or

with, like, a message that there's an error. So it it's it's very funny how they do that, but they're like Yeah. And and I found, I know how many I don't know how many times Wes has gotten the message of error types that you can send a message But what about fixing and logging these errors? of errors. Right? Because oftentimes, like a toast message or a pop up or any of those things, those things are, like, good for My name is Scott.

I will say, Obviously, I'm going to say, but I truly believe because we used Century before we were sponsored by them,

other parts will be successful. So it's it's a wild world there, but I think that's it.

something that you have to be careful about leaking into your your clients because sometimes that things, like we've mentioned several times, could be sensitive.

like, your your database

even even if you have, like, minified code or any of that stuff. Like you had mentioned,

often what that means at the end of the day is before you go ahead and as you get the the payload back, you're simply going to be checking what that payload looks like. And, hopefully, your TypeScript types are telling you that a dot catch onto it. So and all of your variables scoped to the the curly bracket scope.

So different response codes are things that you have to be able to handle on the ESLint. And having a good understanding

validation errors, in your application that may be helpful in that error. And then angle bracket, what's happening is that

it makes sense to just rethrow it. And to rethrow it, you don't need to But then there's also, like, inline errors, like, when you're when you're working in a form. And the reason why you would most likely rather use It's important to know, like, when to use certain types

of a thrown error, But then you can also have ones that are a little higher up that will catch values, and that's really helpful Wes, like, an HTML format or whatever makes sense. So that that can be then you can go ahead and and catch it. The the alternative to that is you can chain

I'm good to go. And, yeah.

and even if you're using async await, I'd like to call this the mix and match, where you can say, like, const user equals await get user, but then you can also just tack a dot catch onto the end of

create a new error or anything. You just say throw

that you wanna display to your user.

which can be really helpful, that little pop up in the bottom right hand corner. Those are really nice because

and use it to attack user accounts or or try to hack into somebody. You want that you want, typically,

what happened, And that's really nice because you can also with an error boundary, you can

So logging is basically

or something like that. The minified those errors are the absolute worst you have to debug. And when there's, like, no source maps available

why don't you need the keyword new? I'm curious about that.

If you do want to construct the error ahead of time, you're creating a new class. And you have an error, whether it's in your own code, whether it's in, like, a a module that you you have have done or whether it's, like, something that you did not totally expect, like your your application has a syntax and and sent it. But if it if if it can't do that, then it was it was interfering with some of the other logic that needed to happen. So those errors are going to be typed as unknown by default because and that can be

Throw me a bone. Throw me a freaking bone here. Yeah. Let me, let me know what's going on. And, I found it to be very ESLint at being able to tell me in plain English oftentimes, users just not using your stuff

passing the original error to the cause property of your your error will make sure that your stack traces stay intact and you're not accidentally losing any information. Word. So okay. We've talked a lot about throwing here, but and we've kind of alluded directly to promises, error in it somewhere, So when and then do something with it, whether that is logging it out, whether that is displaying some UI to your user, whether that is retrying that specific logic.

Very common, especially today.

specific logs to be able to determine what happened. But with Sentry, it's kinda cool because

if you are trying to transform

has been adding, you know, AI features into their their application because it's good at that kind of stuff. It's parsing a lot of information.

you are going to need to handle that. You're gonna have to catch that specific error,

again, this sounds like an ad.

and stuff like that would be something like password invalid, especially if there's a promise involved, or a a dot catch on a promise,

you're going to then go ahead and and catch that error and decide how it happens. So

I've recently found out they are a customer of centuries.

hey. I'm gonna be a little bit late. Gotta head to the urgent care. Hurt myself in some way.

if it's not your code,

throwing it in a pop up's always an option. Right? Yeah. Yeah. No. Totally.

what to do with them, when you should be throwing one versus returning some data just with some errors in it that's the point where I still send it off to Century. Because I'm like, I know this should never happen, but I'm gonna go send it off. Because if it does, I'm certainly gonna need to know Wes. Simply just wrapped the whole route in, like, a try catch. And they're like, well, we should probably wrap this whole thing. I think we've covered all of our bases, but just in case and then they throw some sort of, like, generic error or or something that is misleading,

logging and storing the errors, telling you how many times they've happened,

the reality is that

because, yeah, in development, you're you're you might be in incurring these errors, and, typically, it's happening while you're using the app, so maybe you can go find it and fix it.

is is up to you, but there's numerous ways of taking care of that from there. Yeah. Inside of an error is a few things. Because when you throw an error, you are using the keyword throw,

and that will But sometimes both of those can gum up your flow control quite a bit or to a point where,

what's the deal here? What's going on? Hey.

So, yeah, they glued they glued me up.

You will see this code a lot where people are catching the error and then throwing a new error that has not been modified at all. You don't need to do that. You just throw the error.

or that promise based function.

it will Big fan of that because, like, your your JavaScript, in this use case. So

There's also a handful of node system specific errors, but we don't need to get into them too much,

have both your error and your successful return data available at the same level Mhmm. Without any weird scoping thing. So in that case, you have to then create a new one, and then you can throw it at a later ESLint, but the new keyword is not necessary, which I had no idea. I was adding new for probably my entire career, but

HTTP response codes.

Yeah. Error boundaries.

pnpm error, but error and error handling. Then we'll get into what's in an error, and then we'll dive into all of the different types of errors that can be thrown, how to deal with the synchronous versus synchronous code, client side versus server side, message to it or you're, like, trying to rephrase it, it is helpful to pass the on the client, on the server, how to throw your own custom errors,

server errors.

200 through two ninety nine are success codes.

or it's not clear where exactly the error is take like, actually taking place. Because the error can originate or end up somewhere, and and, like, the actual bug or, you know, whatever in your code might not necessarily be super obvious

different ways to, like, log an error. Like, sometimes you may you may catch an error, and you, like, you you don't wanna log that because you've you successfully caught it and you successfully dealt with it.

to create a new error if you're catching and just continue it down the line. Mhmm. Let's talk about client side errors.

So there's also personally, through a try catch block

have, like, a database lookup or, like, like not a not database lookup, but, like, a map lookup. Meaning that, like, these are the possible errors that I know of, and here are the friendly texts that I can do. And often, those are Or I I like, I think so. Right? Like, you can Yes. You can return a status code that is an error, but still return Alright. Well, let's get on into it. We're first going to dive into TypeScript has no idea what the shape of that is going to be. There is no way to type the type at a generally, at a higher level, in a specific way, and we can continue on. While others Wes it's like, generally, you'll put those as as close as possible to

I got, like, a smart IR blaster.

and and there's more information, they become I think logging becomes more useful, which not more useful than capturing errors, but, like,

pings the API

And,

do you do you return a status code which is relatively new. And if you are you don't always have a good UI for displaying it happened at this point, and you can kinda take it from there.

a bit a bit of a problem as well where,

Because you can certainly then log that error in a way that makes sense for, to the client to let them know that something is going wrong, but then we're handling it on our own, anytime you do any type of log,

If anything goes wrong at any point, I am simply just going to throw. I'm going to throw an error. You can pass along the message of that error and any other additional details I've also written this one many times. And, essentially, what it does is when the two string property gets called on that error because they warp to display a string version of the message, then you can, I don't know, database out of room or simply cannot connect to it, then then you're in a little bit more trouble, and you need to all of my API routes function,

Yeah. And sometimes, you know, if you're dealing with, like, library code that fails in the library code, you call a method, you call a function or something, and that fails. Mhmm. The error might not always be something you want to continue to to throw up.

The response is coming in as HTML, and then you're not expecting it to come back as HTML.

Yeah. Yeah. Totally.

for example, you don't wanna, like, wrap your

Yeah. So I found that you can oftentimes if you are having a hard time understanding your stack trace, you can just copy and paste that whole thing, throw it into any AI of your choice and say,

to never be down, that like like, something went wrong along with the the error message? Yes.

in that case, I had to catch that specific error that's my, like, favorite way. There's been a couple proposals in JavaScript to add this natively, about what went wrong

it involves, We also mentioned this already briefly. But in this scenario where you are, like, awaiting something or you're inside of a try catch block, when you catch that error,

how to structure your application so that you can handle them appropriately

Sanity employees,

Yes. And that that's why sometimes when you get an error, you'll get, like, a reference ID as well, because These things happen, and it's good to have the those things in place that you can check for them. These things do happen. That's just how it goes.

But every now and then, you you simply just need logs or you need to be able to, like, look up your logs and see how often something happens. So Welcome to Syndax today. We have an episode for you on errors,

you have in here that you don't need to use the word new. Sometimes you use the word throw new and then capital e error and then what happened, but, like, or just simply something failed here or there, whatever.

like validation error extends error, and

Quick trip to the

But at other levels, you simply just wanna have, like, a a site wide error that you wanna wanna display. Right? So you can simply just throw, like, you don't care inside of a component, and you knowing that somewhere higher in the the component tree is going to successfully catch that and be able to display it to your user. Yeah. You ready to get into server errors? Yes. Yes. Let's talk about it. Let's talk about override the TypeScript property on that class, tag or component that will catch any errors that are happening inside of it. And that's really nice because you could wrap an error boundary around a component like a form and catch anything that happens inside of there.

never And and sometimes you may you may catch an error and go, oh, that that shouldn't this should never happen. Like, if you ever have code where you have this should never happen or or whatever,

to create a new error from that error, and then you can just pass the current error in. You can give it a cause maybe about whatever 400 through four ninety nine are a client error, you know, 404.

with just the regular issues in something like Sanity.

And that's really nice because then you can

The problem here is that people can just do anything. So that Yes. Sometimes people do the wackiest stuff. And, how many users or which user they happen to, what browser,

you can put the catch below it and say, if any of these things, and then, oh, that already exists. Let me look it up and and continue on. I probably would look it up first, but that's kinda besides the point. Right? You may say, okay. That that error, we can we can handle,

handle and store and log these errors is something that I think is very important.

I had a contextual

you know, if any of these things were to go wrong, you don't have to handle every single one individually,

not and I just think it goes a long way. You know? Your users probably aren't gonna be aware of this either way. You wanna make sure your users are handled carefully, but it does, like the worst possible thing is for you your app to be causing numerous issues for several users and for you not to be aware of it. Yeah. You have no idea.

you have a tuple or or something like that of either an error or data, your function in a promise dot try will allow you to

someone's throwing me a ball. I catch it. Yep. I can either then throw that ball again, or maybe I can take that ball and put it in a bucket and handle it later or just drop it on the ground and pretend it didn't happen. Or providing like, if you are providing additional context you're trying to give it. But, yes, you do not need to

that to never happen. Like, Node example was I expected my explaining a few

or at least I'm a Sentry employee, we're we're able I guess you're a Sentry. Sentry shills is the correct word, Scott. Sanity shills. This is something we're very familiar with. So

So, the thing is the perf. I could've in the time, I could've

Yeah. Yeah. Alright. Cool. Well, I I don't got anything else. Thank you so much for watching.

will scope the error inside of either inside of a function or inside of a block, and then it can be hard to return from a dot catch. Mhmm. It's it's hard to return from the parent. You can't return from the parent function. Right? And then a try catch is Node you have your errors in your your code

and I expected it to work and I look away from my phone because I'm have ADHD and I get distracted, and I look back and it didn't submit, what version of your application, Again, we we've mentioned a little bit about server errors through the the course of this. But, really, again, server errors are that, you know, JS, ESLint error when you're working in in a form is that it provides

an error of this type, if it were to go. I I kinda really want that. But if that happens, Svelte is getting it or Svelte does have it now, I believe.

you could catch

Now both the try catch and the dot catch are they have their own use cases,

Yeah. If you're putting on on a scale of, like, what's most important to least important, I think logging and capturing

the user of this library wants to deal with something going wrong. So, therefore, I am simply going to throw, and you have to figure it out at a different point.

that is the word that we use there is is thrown. Right? An error is thrown. And then when you want to handle that error,

I'm doing alright.

you can try having to, like, figure out these obtuse source map errors that are just, like, not pointing to the wrong right part

the stack trace can get a little bit ugly,

I wrap every single route in a high order function, and that will then catch it and send a a JSON API and then, like, what do you actually do with them? So first of all, the wording around errors, specifically, we're talking about JavaScript here, but this will work in a lot of other languages JS the whole idea of, like, thrown and catching.

This is something

Plus, like, in GraphQL world JS there's a possibility that part of your payload to be expected and you do want to continue.

and just let us know what you what you're doing.

which is probably one of the reasons why Century And then there's the stack.

more useful than if it's just a big old dump all the logs.

Sometimes see those as error, Node, e n t, if you're dealing with the file system.

it's good to know exactly what's going on.

And those can be handled in any sort of different ways. The exception to this is if you're using something like GraphQL,

Cool. Well, anything else on errors from your end?

instant feedback your errors as if it were a promise

well, potentially,

you may want to throw an error versus have to handle it directly in that function. So if you Yarn, is is really tricky.

way back when, I've been using Century forever

Yes. You can look at what was what your logs on the server were doing. You don't have to, like, piece those things together, which can can be really helpful.

having a tool, whatever that tool may be, does not have to be Sentry to capture these errors, I do think goes a long way for your, user not found, unauthorized,

Let us know your tips on on how to handle errors or bridge also, like, your design patterns as to, like, where how do you throw, where do you throw, how do you display them. I think that's also really useful because I've certainly been in lots of applications where

when we are trying to catch an error, Yeah. Not the first time, Wes. Time? Yes. Oh my gosh.

and you sometimes

abandon all ship and and send something back to the user. Yeah. You could think about it like We also have promise dot try, So one way that I like to do is use a package called awaited two, thrown on. That can be very helpful because But if you're not at a layer of your application, or the source maps aren't working and, like, I I feel sorry for anyone who has to spend their days. I know a lot of the folks at Century Yeah. Have to deal with this. But, man,

500 through five ninety nine are server errors. You could think of it as like an what is it? It's four four zero Node. That's unauthorized. Right? 500 is normally like something went wrong on the server. Right?

then I'll return the error in JSON format. Otherwise, you can return the error in,