909: Handling and Throwing Errors

We break down how to properly throw, catch, and log errors in JavaScript and TypeScript. They cover client-side and server-side strategies, using tools like Sentry, and how to handle errors without taking down your whole app. Show Notes 00:00 Welcome to Syntax! 01:19 Error terminology. 01:42 Thrown and catching. 03:01 What’s in an error. 04:09 Name and message. 04:42 Stack. 07:12 Node system errors. 07:34 Messages: strings, objects, or custom errors. 08:19 Throwing errors. 12:01 Promise errors. 12:10 Try catch block, .catch(). 14:13 Using awaited-to. 15:10 Finally. 16:29 promise.try() 17:14 Re-throwing errors. Error Cause 18:12 Client-side errors. 18:15 Catching at different levels. 18:51 Displaying errors. 21:59 Transforming server errors into client errors. 24:12 Error boundaries. 25:26 Server errors. 26:10 JSON API. 27:41 HTTP response codes. 30:09 Logging and solving errors. 31:16 Proudly supported by Sentry.io. Logging within Sentry 36:16 TypeScript and errors. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syndax. Today, we have an episode for you on errors. How to handle them, how to throw them, what they contain. Our application is full of errors. I write a lot of errors myself. And how to structure your application so that you can handle them appropriately on the client, on the server, how to throw your own custom errors, what to do with them, when you should be throwing one versus returning some data just with some errors in it 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 Bows, developer from Canada. With me as always is Scott. How are you doing today, Scott?

• 0:42Scott Tolinski?

  Doing all right. A quick trip to the urgent care for a cut finger this morning. But hey, man, yeah, not the first time, Wes.

• 0:49Wes Bos?

  Not the first time. Oh, my gosh.

• 0:51Scott Tolinski?

  I know. How many, I don't know how many times Wes has gotten the message that, hey, I'm gonna be a little bit late, gotta head to the urgent care, hurt myself in some way. So yeah, they glued, they glued me up. I'm good to go. And yeah, feeling like this is just my life. That's just how it goes. I gotta chill out, I think.

• 1:19Wes Bos?

  All right, well, let's get on into it. We're first going to dive into explaining a few specific words about error and error handling. Then we'll get into what's in an error and then we'll dive into all the different types of errors that can be thrown, how to deal with the synchronous versus synchronous code, client side versus server side. 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, is the whole idea of like thrown and catching. So when you have an error, whether it's in your own code, whether it's in like a module that you have done, or whether it's like something that you did not totally expect,

• 2:04Wes Bos?

  like your, your application has a syntax error in it somewhere. That is the word that we use there. Is thrown, right? An error is thrown. And then when you want to handle that error, 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. Something went wrong. You simply throw it. Ah, this didn't work. You throw it out there and then somewhere else in your application, you are going to need to handle that. You're going to have to catch that specific error 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.

• 2:44Scott Tolinski?

  Yeah, I do like that that visual of throwing a ball because it is just like, I got a problem over here.

• 2:49Wes Bos?

  Sad. Yeah.

• 2:51Scott Tolinski?

  Now you're gonna have a problem over there and and how you handle it is is up to you, but there's numerous ways of taking care of that from there. Inside of an error is a few things because when you throw an error, you are using the keyword throw and sometimes 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, why don't you need the keyword new? I'm curious about that.

• 3:22Wes Bos?

  Yeah, yeah, you don't need the new keyword when you are throwing. So if you're simply just throwing a new error, you can you can just throw error. If you do want to construct the error ahead of time, you're creating a new class. And in that case, you have to then create a new one and then you can throw it at a later point. But the new keyword is not necessary, which I had no idea. I was adding new for probably my entire career, but think of the perf I could have in the time I could have saved.

• 3:51Scott Tolinski?

  By not constructing a new instance and even if there there's some, you know, thought there too. If if you're catching an error that exists and then 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 class instance, inside of this bundle here is a few things. There's a name. The default is capital E error. 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, uh, user not found, unauthorized, or just simply something failed here or there, whatever.

• 4:34Scott Tolinski?

  Uh, these types of things could get thrown inside of your application. And then there's the stack. Uh, Wes, do you want to explain what the stack is?

• 4:42Wes Bos?

  Yeah, the stack is a stack trace leading up sort of a treasure trail for where it went wrong and it will show you essentially what function called what function, what called what function? And it will show you which files and line numbers they were actually thrown on. That can be very helpful because sometimes your stack trace is going to be, is going to show you that the error went wrong. Either in like a node module or in a, a, a module library, or it's going to show you that it like happened like deep within the internals of V8 or Node JS, which is not that helpful. But if you can sort of back it up several levels and, and read the stack trace,

• 5:24Wes Bos?

  then you can see, okay, it happened in my code, you know, the stuff that I can control. It happened at this point and you can kind of take it from there.

• 5:33Scott Tolinski?

  Yeah. And, and I found personally this to be a situation where AI can actually really help you. Because sometimes the stack trace can get a little bit ugly. Or it's not clear where exactly the error is taking, like actually taking place. Cause the error can originate or end up somewhere and like the actual bug or, you know, whatever in your code might not necessarily be super obvious. Even if you have like minified code or any of that stuff, like you had mentioned, the, the error could take place on line one character, you know, 2 million or something like that.

• 6:11Wes Bos?

  Yeah, the minified, those errors are the absolute worst to have to debug. And when there's like no source maps available 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 Sentry.

• 6:25Scott Tolinski?

  Yeah.

• 6:25Wes Bos?

  Have to deal with this, but man, try having to like figure out these obtuse source map errors that are just like not pointing to the wrong right part. Is really tricky.

• 6:36Scott Tolinski?

  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, What's the deal here? What's going on? Hey, throw me a bone. Throw me a freaking bone here. Yeah, let me, uh, let me know what's going on. And I found it to be very excellent at being able to tell me in plain English oftentimes, which is probably one of the reasons why Sentry 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. There's also a handful of node system specific errors, but we don't need to get into them too much.

• 7:17Scott Tolinski?

  Like code, you sometimes see those as error, no ENT. If you're dealing with the file system, there's syscall, path, desk. 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 system packages.

• 7:35Wes Bos?

  One more thing is, is when you're throwing an error 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 into a string. But the message itself can be, it can be several types, right? You could, you can throw an object in there as well. If you are creating a custom error, so you use a class like validation error extends error, you can override the to string property on that class. And that will, when the to string property gets called on that error, because they want to display a string version of the message, then you can implement your own logic there as to, to how to display that.

• 8:18Scott Tolinski?

  Yeah.

• 8:19Wes Bos?

  Throwing errors, let's talk about it. So you, when you're writing your logic in your, your JavaScript, you may want to throw an error versus have to handle it directly in that function. So if you are writing logic and you say, I don't necessarily care how this error is handled, because I am simply doing some validation or doing a database lookup. 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 that may be helpful in that error. And then.

• 8:57Wes Bos?

  At a generally at a higher level, you're going to then go ahead and catch that error and decide how it happens. So sometimes it makes more sense to just handle it right away inside of your application. But if you're not at a layer of your application, especially with like library code, I don't necessarily know how 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.

• 9:30Scott Tolinski?

  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. The error might not always be something you want to continue to throw up. So like you could catch the error from a library method or function and then create a new error based on something that you would rather handle in a specific way. Like for instance, like insert failed or something that rather than something that has more context. Because you can certainly then log that error in a way that makes sense for, you know, error handlers or, you know, logging software like Sentry or something to handle that,

• 10:15Scott Tolinski?

  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.

• 10:25Wes Bos?

  Yeah, and there's many cases in your logic where some errors are to be expected and you do want to continue. Like for example, a unique constraint on a database. If you're trying to save like an account and that email is already existing in the database, then you may want to just catch that and then, oh, that already exists. Let me look it up and continue on. I probably would look it up first, but that's kind of just besides the point, right? You may say, okay, that that error we can, we can handle in a specific way and we can continue on. While others where it's like. 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

• 11:11Wes Bos?

  abandon all ship and, and send something back to the user.

• 11:14Scott Tolinski?

  Yeah, you could think about it like someone's throwing me a ball. I catch it.

• 11:18Wes Bos?

  Yeah.

• 11:18Scott Tolinski?

  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.

• 11:27Wes Bos?

  Or providing, like, if you are providing a additional message to it, or you're like trying to rephrase it, it is helpful to pass the cause property to your error. And what that will do is it will not gum up your stack trace. Mean that if you're, if you're catching it and simply throwing it again, you're passing the original error to the cause property of your, your error. We'll make sure, sure that your stack traces stay intact and you're not accidentally losing any information.

• 12:00Scott Tolinski?

  Word. So, okay, we've talked a lot about throwing here, but, and we've kind of alluded directly to promises. 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 through a try catch block or a, a dot catch on a promise. That will then be called the moment that an error has happened. So typically, when we are trying to catch an error, you want to wrap your code, especially if there's a promise involved in a try catch, because that allows you to say like,

• 12:40Scott Tolinski?

  all right, 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 you, how you may.

• 12:50Wes Bos?

  Exactly. 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. And then you can put the catch below it and say, if any of these things, you know, if any of these things were to go wrong, you don't have to handle every single one individually, then you can go ahead and, and catch it. The, the alternative to that is you can chain a dot catch onto it. So. Even if you're using async await, I 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 on to the end of that asynchronous function or that promise based function.

• 13:32Wes Bos?

  Now, both the try catch and the dot catch are, they have their own use cases where they may be useful, but sometimes both of those can gum up your flow control quite a bit or to a point where both of them 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. 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 now you have your errors and your, your code and all of your variables scoped to the, the curly bracket scope.

• 14:13Wes Bos?

  So one way that I like to do is use a package called awaited2. And I've also written this one many times. And essentially what it does is it will, 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. And that's really nice because then you can have both your error and your successful return data available at the same level without any weird scoping thing. So that's my like favorite way. There's been a couple of proposals in JavaScript to add this natively.

• 14:57Wes Bos?

  And I sure hope that we have it.

• 14:59Scott Tolinski?

  Yeah, I, I personally, 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. 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 as well off of just a normal promise, but.

• 15:32Scott Tolinski?

  This runs after a successful or an error. So basically, the catch has happened or the catch has not been triggered. But this will then always run no matter what after either.

• 15:45Wes Bos?

  Regardless of if it was successful or not. That can be really handy for like teardown. You want to remove event listeners or regardless of what happened. Sometimes like you may, something might error. Like a very common one would be if you're trying to report some data to a analytic servers service. Right? There's this high probability that the user will have an ad blocker on. And that fetch or that that post request is going to fail. And if you, if you know, nah, it's, it's half of these are going to fail anyways. It can be helpful just to stick that final logic in your finally. So that you know it's regardless of what happens, I'm going to display this to the user.

• 16:28Scott Tolinski?

  Yes, totally.

• 16:29Wes Bos?

  We also have promise that try, which is relatively new. And if you are writing a bunch of like promise based code. And you have a function that you don't necessarily know if it is promise or not. Or if you simply just want to maintain the same syntax for everything. Wrapping your function in a promise dot try will allow you to handle your errors. As if it were a promise or not. So if you're chaining a whole bunch of stuff and somewhere in that chain. You have a synchronous function that is not returning a promise. You can kind of fake it into a promise with a, by wrapping it in a promise that try.

• 17:13Scott Tolinski?

  Yeah. 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, sometimes it makes sense to just re throw it. And to re throw it, you don't need to create a new error or anything. You just say throw and then the error that comes in from the catch. So you don't have to create a new one. You will see this code a lot where people are catching. 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. If you do need to add additional context, then it makes sense to create a new error from that error.

• 17:56Scott Tolinski?

  And then you can just pass the current error in. You can give it a cause, maybe about whatever additional context you're trying to give it. But yes, you do not need to to create a new error if you're catching and just continue it down the line.

• 18:12Wes Bos?

  Let's talk about client side errors. 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 want to catch these out of UI level where I can display them, right? You may have form submission, validation errors, instant feedback that you want to display to your user. So generally, you'll put those as as close as possible to the UI where it's happening. But at other levels, you simply just want to have like a a site wide error that you want to want to display, right? So back in the olden days before React and whatnot, we had this idea of like flash messages,

• 18:57Wes Bos?

  which you would just, 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. Or, sorry, I can't delete that item because you don't have have access to it. Now those have been replaced mostly with toast errors, which can be really helpful. That little pop up in the bottom right hand corner. Those are really nice because you don't always have a good UI for displaying an error. But throwing it in a pop up is always an option, right?

• 19:32Scott Tolinski?

  Yeah, yeah, no, totally. It's important to know like when to use certain types of errors, right? Because oftentimes, like a toast message or pop up or any of those things, those things are like good for errors that you kind of just want to alert the user of that will be gone in a moment, right? Like, or maybe you give them an X and it has a timer like, you know, try again or something, right? 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 a inline error when you're working in a form is that it provides contextual information and instant feedback to the user, right?

• 20:15Scott Tolinski?

  Where like if, if I, if I submitted my password 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. I would not know what would happen if you were using a toast message because they're usually ephemeral.

• 20:31Wes Bos?

  Oh, that happens to me a lot. Yeah. Or it goes away and I wasn't looking or like I have such a tall screen. Yeah. Yeah. That drives me nuts.

• 20:40Scott Tolinski?

  Drives me nuts. So in those types of instances, it makes way more sense to put that inline contextually. So that way when your user looks at it, it shows you. I had an issue. I had a contextual inline error the other day, Wes, on a, just one of those cheap smart home apps. Um, I got like a smart IR blaster and man, it would not let me create an account. It was like, you know, you get all the, it says, here's the things you gotta do. I got all the checkboxes. All the checkboxes are green. I used 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 could not be more valid. And I tried it several different ways, could not get past it. I'm sure it was probably some kind of error on their side.

• 21:25Wes Bos?

  Oh, that's, that's a really frustrating part is that the, what might've happened there is that their server code 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. And we'll say like, password cannot be created. And that's really frustrating because you have no idea about what went wrong. In that case, or in, in some cases what's happening, and maybe I'll talk about this right now, is that if you are trying to transform server errors into client errors,

• 22:08Wes Bos?

  you often have to like translate them because you don't necessarily want to send. Like your, your database thing, you may have stack traces in there that, that are sensitive. You may have like an actual error message that is sensitive and those should not be actually displayed to your end user. So often what you'll have to do is you'll have to like have like a database lookup or like I'm 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 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

• 22:51Wes Bos?

  a, a very generic error message that gets displayed to the user, which is so frustrating to get.

• 22:58Scott Tolinski?

  Yeah, error messages you do not want to give your users are like email exists, wrong password, or something to indicate if the user actually has an account there. Or like, yeah, you, you don't want to give people anything that they could then use to turn that information and use it to attack user accounts or, or try to hack into somebody. You want that, you want typically like, yeah, the, the helpful messages for authentication and stuff like that would be something like password invalid, but not like account already exists because that is a security issue.

• 23:35Wes Bos?

  Yes, and that, that's why sometimes when you get an error, you'll get like a reference ID as well, because sometimes though they're trying to protect bad people from using those errors to know what hap, what is actually happening. But then you also, if somebody were to email you that, that is legitimate, 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 and then, then help you from there.

• 24:12Wes Bos?

  Uh, error boundaries. This is something that many React has it. Uh, Svelte is getting it or Svelte does have it now, I believe.

• 24:21Scott Tolinski?

  The boundaries, yeah.

• 24:22Wes Bos?

  This is the idea that in your UI, you can write a error boundary 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. Uh, but then you can also have ones that are a little higher up that will catch values. And that's really helpful where, for example, you don't want to like wrap your, your, you don't want your navigation to break if something like small happens on, on your website. You don't have the whole website to break. So you'll often have several levels of error boundaries in your application that will try and catch anything that, that bubbles up.

• 25:07Wes Bos?

  And that's really nice because you can also, with an error boundary, 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.

• 25:25Scott Tolinski?

  Yeah. You ready to get into server errors?

• 25:27Wes Bos?

  Yes, yes. Let's talk about it.

• 25:29Scott Tolinski?

  Let's talk about server errors. Again, we, we've mentioned a little bit about server errors through the, the course of this. But really, again, server errors are something that you have to be careful about leaking into your, your client. Because sometimes that things like we've mentioned several times could be sensitive. And, uh, as we've mentioned already, it's common to have a lookup of error types that you can send a message to the client to let them know that something is going wrong. But then we're handling it on our own, logging it or being able to fix it in the backend without exposing that to the client. So something very important to keep in mind.

• 26:10Wes Bos?

  A JSON API, this is something that I've done quite a bit where I will like wrap all of my API routes for any possible uncot 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, then I wrap every single route in a higher order function and that will then catch it and send a JSON API error to it. Or even even further is I'll check the accept header on the request. And if the request is asking for JSON, then I'll return the error in JSON format. Otherwise, you can return the error in like an HTML format

• 26:53Wes Bos?

  or whatever makes sense. So that that can be a helpful way. If you've ever like had an error on a website and you look in your dev tools and it says cannot read angle bracket or cannot parse angle bracket, what's happening is that an error happened on the server, your client code is assuming that JSON is coming back, but it's not because it's it's sending some HTML back. And often, 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.

• 27:29Scott Tolinski?

  Yeah, that's an easy one to have memorized if that's happening. The response is coming in as HTML and you're not expecting it to come back as HTML. Very common, especially today. So there's also HTTP response codes. So different response codes are things that you have to be able to handle on the client. And having a good understanding 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, 200 through 299 are success codes. 400 through 499 are a client error, you know, 404. 500 through 599 are server errors. You could think of it as like an unauthorized,

• 28:13Scott Tolinski?

  what is it? It's 401, that's unauthorized, right? 500 is normally like something went wrong on the server, right? And those can be handled in any sort of different ways. The exception to this is if you're using something like GraphQL, GraphQL will return a status code of 200 with like a message that there's an error. So it's very funny how they do that, but they're like The reasoning for that is that like they're saying that the the response from GraphQL was success successfully took place, but that response was that there was a problem somewhere.

• 28:50Wes Bos?

  Yes, that that's always a funny like successfully erred. If you are doing server validation and something went wrong in that validation, do you do you return a status code? That like like something went wrong along with the the error message?

• 29:10Scott Tolinski?

  Yes.

• 29:11Wes Bos?

  Or I like, I think so, right? Like you can, you can return a status code that is an error, but still return JSON or whatever format, like a React server component payload that that you're looking for. Plus, like in GraphQL world is there's a possibility that part of your payload will have an error and then other parts will be successful. So it's it's a wild world there, but 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 you have a tuple or something like that of either an error or data, not both.

• 29:55Scott Tolinski?

  The problem here is that people can just do anything. So yes, sometimes people do the wackiest stuff. And if it's not your code, it's good to know exactly what's going on. Otherwise, it's best to follow best practices. But what about fixing and logging these errors? This is something that, you know, as a Sentry employee, or at least I'm a Sentry employee, we're we're able, I guess you're a Sentry.

• 30:23Wes Bos?

  Sentry shills is the correct word, Scott.

• 30:26Scott Tolinski?

  Sentry shills, this is something we're very familiar with. So logging and being able to solve these errors is something that you'll want to do in production specifically. Because yeah, in development, you you might be incurring these errors. And typically it's happening while you're using the app. So maybe you can go find it and fix it. But in in production code, errors just be happy. 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 it involves, well, potentially users just not using your stuff 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're like, oh, wait, I have a special flag on my account specifically,

• 31:10Scott Tolinski?

  or I have some logic that targets my account specifically or not in other users or whatever. There's some mismatch there. So being able to handle and store and log these errors is something that I think is very important. Obviously, I'm going to say, but I truly believe, because we used Sentry before we were sponsored by them, before this podcast was presented by Sentry, like way back when, I've been using Sentry forever. Because it makes so much sense to log and store these errors and it's only gotten better. So they handle logging and storing the errors, telling you how many times they've happened, how many users or which user they happen to, what browser, what version of your application.

• 31:54Scott Tolinski?

  And it makes fixing these things way easier. Because let's say 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 logging generally in Sentry is in open beta. So logging is basically, anytime you do any type of log, 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 you're console logging or console airing anything, I'm just going to collect all those logs and I'm going to give you an interface to be able to find and search for specific logs to be able to determine what happened.

• 32:40Scott Tolinski?

  But with Sentry, it's kind of cool because, again, this sounds like an ad.

• 32:45Scott Tolinski?

  I genuinely think this is cool. They can attach it directly to your spans and errors to be like, contextually, this error and this log are related to each other.

• 32:54Wes Bos?

  This explicit one, you can, when an error happened to a specific user, 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 be really helpful. I'm a big fan of that because like. Obviously, I think you should be able to solve a lot of your problems with just of regular issues in something like Sentry, 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 I'm actually excited about having that.

• 33:30Scott Tolinski?

  Yeah, i- if you're putting on on the scale of like what's most important to least important, I think logging and capturing errors specifically is is the most important. And like logging is less important, but when they when they're contextual and and there's more information, they become like I think logging becomes more useful, which not more useful than capturing errors, but like more useful than if it's just a big old dump all the logs.

• 33:58Wes Bos?

  We should also say there's like kind of like two different ways to like log an error. Like sometimes you may you may catch an error and you like you you don't want to log that because you've you successfully caught it and you successfully dealt with it. 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, that's the point where I still send it off to Sentry 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 what happened in this use case. So never write code where

• 34:39Wes Bos?

  you don't think an error should happen. I'll I'll tell you that because I've I've had my course platform crash several times where there was simple things where I just expected that to never happen. Like one example was I expected my email SMTP to never be down. Or I didn't I didn't account for that possibly being an issue, right? It just pings the API 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 in that case, I had to catch that specific error. And then throw it into a queue to retry at a different point.

• 35:21Scott Tolinski?

  Yeah, yeah, totally. I will say, 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, I just think it goes a long way. You know, your users probably aren't going to be aware of this either way. You want to make sure your users are handled carefully, but it does, like, the worst possible thing is for your app to be causing numerous issues for several users and for you not to be aware of it.

• 35:49Wes Bos?

  Yeah, you have no idea.

• 35:50Scott Tolinski?

  Yeah, you have no idea. In fact, I do, I was playing a game, Claire Obscure Expedition 33. Fantastic game. I've been playing it for a bit and I recently found out they are a customer of Sentry's. 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. And I'll move on from this crash, but they got that crash. I'm very confident they got that crash.

• 36:16Wes Bos?

  Alright, well, we'll talk real quick about not, about TypeScript errors or errors in TypeScript, not necessarily like, like 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 go ahead and use them, those errors are going to be typed as unknown by default because the reality is that TypeScript has no idea what the shape of that is going to be. There is no way to type the type of a thrown error in TypeScript, meaning that you cannot say, JSDoc you can, but you cannot say this function throws an error of this type, if it were to go, I kind of really want that, but if that happens,

• 37:01Wes Bos?

  the errors are unknown by default, meaning that before you go ahead and use them, 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 function 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,

• 37:30Wes Bos?

  Like you said, you can do whatever you want with the errors, but you gotta first check what there is, which is sometimes very frustrating inside of TypeScript. But believe me, I've hit many instances where I assumed something would be of a specific type because I can't imagine, I can't fathom why it would ever look like that. But these things happen and it's good to have the, those things in place that you can check for them.

• 37:57Scott Tolinski?

  These things do happen. That's just how it goes. Cool. Well, anything else on errors from your end?

• 38:04Wes Bos?

  I think that's it. It let us know your tips on, on how to handle errors or 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 there's no like structure to how to handle them. It's just a bit of a mishmash and that can be a bit of a problem as well where there's no nice way to do it and the UI is all, all gunked up.

• 38:37Scott Tolinski?

  Yeah. Yeah. All right. Cool. Well, I don't got anything else. Thank you so much for watching. I'm curious, like you said, strategies, all that kind of stuff. So leave a comment below and just let us know what you, what you're doing.

• 38:50Wes Bos?

  And go to centri.io forward slash syntax FM to get two months for free of the team plan.

• 38:55Scott Tolinski?

  Yeah, do that. Peace.