OpenJS Foundation Node + JS Interactive 2019, 11 May 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Getting the Most out of JavaScript Errors - Ben Vinegar, Sentry

Description

Getting the Most out of JavaScript Errors - Ben Vinegar, Sentry
Speakers: Ben Vinegar
For years, "logging errors" from web apps meant piping Apache errors into var/log/httpd/error_log. It's only recently that that changes in technology have made it possible to collect, report, and aggregate errors directly from JavaScript in the browser. But until you understand how the Error object works, how stack traces are generated, and how global error collection handlers operate, you'll have a hard time making sense of it all. In this talk, we deep dive into these topics to help you better understand the problems being reported from browser JavaScript environments – to ultimately help you build better applications.

A

Module come on so that it's a bubble yeah, so my name's Ben and I'm here to talk about JavaScript errors. Really this is kind of a deep dive into the error object and how stack traces are generated, and you know a whole bunch of that. So we can come away, hopefully learning a little bit more about how errors work, so we can use them more effectively in our own applications.

A

I work for a company called century we're one of the sponsors here today century is a mostly open source platform, web service and client library, collection for servicing errors from many different platforms, be they know, Jess or Ruby, or Unreal, Engine or iOS.

A

Obviously, here to talk about JavaScript. If you are curious, it's very simple: you just sort of npm install a library initialize that in your express application or browser JavaScript application, and once you do that, once any kind of errors are thrown, you kind of get these really nifty dashboards that give you you know, sack trace with surrounding source code. You know event, volume, etc.

A

It's on github. You can run it yourself. I'll talk a little bit more about it at the end, there's some other screenshots. So if you've ever struggled with situations like the following, where maybe you're looking on your console or an arrow Toolik century- and you see, uncut object object. What does that mean not very helpful or maybe you've got an error? It's just a message and there's no stat trace very frustrating, don't understand how that happened or you've seen this.

A

This is like a browser, JavaScript era called script error and which you know that something's wrong, but that's pretty much as far as it goes. If you're suffering from some of these symptoms, I'm hopeful that we can learn some things to fix that. So in this talk, I'm going to talk about the error object itself, how you can extend that to create custom errors, the stack property and how stack traces are generated.

A

What does it mean to throw other objects besides errors and then a little bit about now that you know you know how the air object works and now you try and catch them all this jazz. How can you report on those errors to like a logging facility or some other tool? So if this doesn't interest you at all you, you should make way right now, so the error object itself where it all begins. So this is, you know from mdn. The error. Constructor creates an error object.

A

Instances of error objects are thrown when runtime errors occur. The error object can also be used as a base object for user-defined exceptions. Pretty concise, really want to focus on that instances of our objects are thrown when runtime errors occur. So what that means is that let's say that you have code like the following: it's it's written sort of backwards. That's intentional, but just take a moment to read it.

A

It's kind of like this cascading waterfall of function calls where a calls be be calls C and then C calls this function, D, which doesn't exist and, as we all know, that's probably not going to work. Something's gonna happen and it's gonna look like this. Uncut reference error D is not defined. This is what you'd see you know. Maybe your node application will just stop and throw this out or you'll see this in the browser.

A

Console thing is, is in the background, if you were to do this instead, you can actually throw your own reference here. There's nothing special about that. It's an error, object that exists or is subclass from here, and you can throw it, and if you did this you, actually it's the exact same stack trace. You wouldn't know the difference. Okay, so all this to say is that when you actually, you know, throw a runtime error like this, because your code isn't execute behind the scenes.

A

It's really just creating an error, object and stands Jaden it and then throwing it.

A

So you don't have to you know. Obviously you know to throw reference errors. You can throw the base error object itself, and if you do that, you can see how the output is a little bit different in this case use the uncut error. This is super broken, but the same stack trace generates from that point.

A

The error object has like three major components. In my mind, it has the names. That's like you know, just as we saw reference error, that's the name of the air. That's actually a property on the error, object that you can inspect. There's the message and that's the like. The first parameter that you pass to the air constructor and then the stack there's also a property, and these are like actually values that you can inspect on the air object itself.

A

So if I went back to that example, and if, instead of throwing the error and sort of like letting that bubble up to, you know letting the program crash I, instead try try and catch it. I can inspect the values of that air object and output them to the console, and you can see that they look like this. So just that you know that these are. These are things that you can navigate and inspect yourself.

A

There's a bunch of standard errors that are kind of like built into built into JavaScript, I, don't know if all these are in node, they certainly are in the browser right, for example, URI air that probably exists not sure, but these all derived from airs and they sort of are built into the built into the runtime, some of which you may have not seen before internal error is when the actual underlying JavaScript engine has exploded in a way that it doesn't understand.

A

So, if you do see that it means that you know, v8 has is not happy. Eval err happens. If you try to like run eval in the global scope. Things like this, you could use these yourself. If you wanted to there's nothing again, they're not protected in any way you can throw them yourself. What is perhaps more practical, though, is to sort of extend the air class yourself to create your own custom air classes. That might actually add more contextual information that you might want to add.

A

So in this very simple, like super simple example, all I'm doing here is extending the air object and.

A

Just giving it a different name, you actually have to override that name property. You can, you know, JavaScript doesn't magically know to look at that. You know class variable and just sort of transport that to the name property. So you have to declare yourself and now you can throw this air and I will do just just as it will operate the same way as every other error example. We've seen okay, this doesn't this example. Right here doesn't really do much other than to create a new. Like name of an era.

A

You know that could be useful. Maybe a more useful example is, if, like you, were building an API and you could create your own air class called the API air class, and you can augment that at a status code. Maybe you could add some headers or some other values and the reason you would do that is that maybe, when you're inspecting these values later in your application, you're dumping them your console logging them. You can actually like output.

A

That information, which could tell you a little bit more than just sort of a you, know a stack trace below this is sort of an example where you can try some code. You can catch it. You actually see if it's an instances, API error, in which case you can sort of like you know that you can carefully extract that status, property that wouldn't otherwise exist.

A

Okay, so that's just the ear object. It's not nothing too crazy. I! Think the most interesting part is the stack trace. It's the most useful thing. It shows us, you know what were the the frames that we're executing before the thing broke. It's the thing, that's going to tell you where your application stopped working. So, like I mentioned, it is like a property property on the air object, it's actually like a prototype property.

A

So how does it saturates get generated? Some people I, don't know. If you're not aware the stack trace is actually generated at the moment at which the air object is instantiated. Some people might believe that it's actually, when you throw the exception, as in the examples that we had.

A

So if you have this example, looks like looks like earlier. The difference here is that I'm creating an error and then I'm returning it through the function waterfall all the way to the top and then throwing it there. The throw point doesn't matter because the error was created in that like C function, the stack trace that you can see there in the bottom right still kind of Cascades. The same way something take away is that it's on air creations when the stack trace is generated.

A

But that means that this is a pattern that sometimes you know we use an application developer, just to sort of like catch a generic error and because we know more about it, we might re throw one of our custom errors. So, for example, what if I caught an error and I read through my API API err and I want to add like a status code.

A

If you, if you do that, oops sorry getting out of myself, if you read through of an existing error, you won't actually change the stack trace right, so I can catch it. I could throw it again and there's no problem and look exactly the same, so you can catch and throw and catch and throw the sector is still originated. This is what it's getting into, which is, if Yuri, throw this as a new error object right, like my custom here, I'm just getting ahead of myself.

A

Sorry, in this case, you actually generate a new stack trace and that's because you create a new air object instantiate at that point, and this could be problematic if your, if you're doing this like not carefully because you're actually eliminating all that original context, that you were catching so something to be aware of um if you've ever dealt with a stack trace and you feel like it's missing frames. This is a possibility.

A

What you can do instead is that, if you are throwing your own custom errors, you can actually copy over. The original error stack trace on to that new, like custom error, object, you've created in this case, I'm calling it like original stack, and this way you kind of get both you get the stack trace, leading up to your custom error, but you also get that original saturates that bubbled up. You can also just completely override it. If you want there's nothing stopping you from doing that, everybody following so far I go too fast.

A

Okay, not on me good.

A

Yeah, so everything that we've been talking about so far are these these these synchronous code examples, but we all know that javascript has like a lot of asynchronous code, it's one of things that makes it cool challenging.

A

My problem with that is that the stack property it really only bubbles up to like the topmost asynchronous frame. So let's say that we have the same example: a calls B B call C, but then C kind of breaks out. This set timeout function, which you know cues up a call that gets executed, executed, asynchronously and then in that function that gets executed. We now try to call the function D, which doesn't exist in this example. Unfortunately, you just get this okay.

A

The fact that there is this sort of, like you know, cascade of function, calls that queued all this code up, it's lost and that really stinks very frustrating. This is something you should keep in mind. Now you might be thinking this is a node conference. I've heard a lot about node 12 and has a synchronous, asynchronous stack. Traces is a thing.

A

Full disclosure here, I'm, not like a full time. Node developer I'm, it's more of a curiosity for me. I I'm, mostly like a browser, JavaScript developer, but I was playing around with this and this example. This example right here. If you try, this in node, 12 you'll actually get the same result. You you've lost sort of like that. The outer context calling that set timeout, but there are some patterns in that you can use no.12 which actually give you like a full like asynchronous stack trace.

A

They involve so if you're, using promises, you're using async await- and you have this example, which is a little it's actually very subtly different from the other one node twelve will sort of provides you. This asynchronous call stack. It doesn't capture every sort of asynchronous call stacked. It's just sort of like particular patterns that it's aware of in which it can generate this, and it's usually using async can await.

A

Chrome, however, if you have dev tools, open and use that earlier example that I had this example doesn't try catch the like runtime error it instead, just it just lets it explode. If you run this in chrome today in dev tools, you actually get this really nice output. That is pretty handy. It shows you, it has a different format, but it shows you these sort of sort of like asynchronous calls, and this is really great. This gives you kind of everything you need to figure out. Why why the code was broken.

A

A challenge here, though, is that this is actually just like the developer console. It isn't actually, even though Chrome and VA kind of has all the information it needs to sort of augment that error object with a stack property that would have this information it doesn't. This is strictly just what you get in the console output and if you were sort of like logging, this in the example that I had before you lose these frames. This is all really silly.

A

Okay, so like different, obviously like different runtimes interpret air stack traces in different ways, and that's because this property, the stack property, is so useful that we depended on it's actually non-standard, the presence of it. The idea that it exists that there is some property named stack, that is standardized, but what is inside of it is sort of like a free-for-all.

A

It's not defined so perhaps in the future, all those asynchronous sort of like patterns will emerge or they'll get like extended on to the stack property for the error object, and that would be fine, because it's not standardized so there's nothing really saying that it can't.

A

What that means today is that if you look at stack traces from different sort of like browsers and different JavaScript runtimes, they all kind of output, these stack traces in different ways, so chrome v8, sort of output, for example they redundantly output, the error name and the message on top of the stack. So this is me just outputting the stack property. It includes that redundant information Safari omits that information has a different way of sort of like showing you frames. Firefox is another way as well.

A

What this means is that, if you're doing sort of like error reporting- and you want to kind of like group, different errors together, you have to do a whole bunch of like reg, X, massaging and things. If you were so, it's so inclined so stack property couple key takeaways its generated instantiation. We throwing the new air the same air will not generate a new stack trace, but if you create a new air, obviously you will. The first frame is the topmost a synchronous execution, except for in some cases it's just a string right.

A

So everything I've shown you it's not. This is not some clever way. They are like array that you can manipulate. It's just all string data and it's non-standard so so far been showing these examples, where we throw errors which is like the really good way of you know, throwing things if you want to stop execution in other languages. If you try to throw or raise an exception, using a non error object that act in of itself will create an exception.

A

So if I in this example with Python, if I try to raise a string, it basically is like whoa whoa. You can't do that. That's that's not how this language works. Javascript, however, is perfectly quite content to let you throw anything so in this example similar as before functions, a B and C, and then I throw this string called oops at the very top. If I do this and I try to catch it and I try to log it you just get this.

A

You just get the string, oops, there's no stack trace, there's no message, there's no nothing, and so, if you've ever like been logging errors and you and you see just like random strings or things that you don't understand oftentimes, this is the case. It doesn't have to be string, could be an object just like any non err, object and I. Think with the stack property you'll get something like this object object.

A

Now, it's not very common for people to say you know, throw a string. What I think is more common. That I've seen is that when people are doing like promise rejections, they might say, hey I'm gonna, reject this promise with a null value or negative one or something, and if you do that, it's the same story, you're kind of you're kind of deriving you're, not deriving you're, preventing yourself from doing like post hoc debugging of that data, because there's no stack trace.

A

So if you are working with promises and you have an opportunity, you should create error objects, as opposed to just resolving things with like primitive values. Or you know you know. No, there are global, like promise handlers that can help. You find you know things that don't resolve. So that's only going to be useful utility for you. If you actually have a stack trace to help. You understand where those rejections occurred.

A

If you know that this is happening in your code, you'd like to stop it, there are actually some like esn't rules that you can. You can add to your software. You know code repository right now, that'll, look for these patterns and encourage you to resolve promises with err objects and, if you're interested with that, there's no throw literal. That's for preventing you from like throwing strings and objects and then prefer promise reject errors. Is another rule. You can use to stop that.

A

So earlier we learned about how you know you can use this fact that when you create an error, object or you instantiate it, you I should get a stack property. You can use that in useful ways. So in this example, let's say that you know that you have a string, that's thrown somewhere, and this is really challenging because you, you don't know where it is right.

A

This is a very contrived example where I'm throwing a literal value, but what, if you're, throwing some variable, that's being passed around right, very hard to track down a technique that you can use is that you can try and catch some problematic code, and if you know that this error is not an instance of an error, you can actually throw a new air at that point in time, in which case they're kind of like generate what I call like a synthetic trace where you Oh sex race, up to the point where you caught it and that's not obviously like it's not going to get you all the way to the root of your problem, but it at least gives you kind of like a starting place and from there you can kind of, like add more try-catch statements with these synthetic traces to kind of get you closer to the problem.

A

There's other useful ways of using this. Like stack property like, if you just want to you, don't have to throw an error right, you can just create an error, object, console.log the stack or put the stack properties preserve it in a way that is useful for you and toss the error way. That's perfectly valid as well so non-air exceptions there cause when you throw any non error, they make determining root-cause difficult cuz, you gotta know stat, trace promises, comments, or so that I mean you can use.

A

This error object to help you out so up until this point or kind of talking about the error object, ways to use it a little bit more effectively or at least to understand how its operating. So you know what you're looking at I talk really briefly and just like what, if you want to report on those errors, here's a really contrived example like if I try, some code, problematic code, it blows up, I can catch it and then I can use fetch or node fetch to send some data to an error, reporting endpoint.

A

This could be a logging endpoint or something you've stood up. I'm not gonna, go to the details of that. Of course, you don't really want to pepper your code with try-catch statements, especially because we, you know, try catch, only works on asynchronous boundaries. You have to do it a little all over the place, so most Travis runtimes provide you like global air facilities, they're collecting facilities that you can use to collect them, and no, this is you can use process that on uncaught exception and you can use that catch.

A

An air try to make a HTTP request somewhere. But if you do this, you should be really painfully aware that this actually subverts the.

A

You know your your program, your program holding, so you have to do it yourself and the docs will tell you that you should really only run synchronous code in this air handler because, if, if it doesn't exit there's a chance that your your application might be still running and some sort of like undefined state, while you're trying to do cleanup so something to keep in mind like I, would argue even that's a really contrived example.

A

I wrote is not very safe because it's basically saying okay, the program halted: I'm gonna, just gonna send this err report somewhere and while I'm waiting for that to return, my application is going to run in an undefined state and then I'm gonna process exit, but I just wrote this. It's just like a really contrived example, because dealing with us in a safe way is too complicated for one slide.

A

Similarly, there is you can use that same sort of event handler for unhandled rejection, this the callback for this as it takes a reason which is you know. Why was this? Actually, you know why was this promise rejected, which is typically an error, and if it is an error, you can of course extract it and send it just like in the example before in this case this doesn't like halt operation of your program, so you can kind of do this much more safely in browser world.

A

It's a little trickier browser world has this window dot on a global handler that is really like a relic that dates back all the way back to the 90s, and so it's sort of just kind of been. We just been tacking on parameters until it's been useful, so you know in order to preserve backwards compatibility. So that's why it has all these arguments. So if you you know, if you're curious, the very first iteration just took like a message and then I took a URL then took a line.

A

Then we're like yeah Colin would be useful too. Let's throw that on there and then. Finally, we just sort of added this, like final fifth error, object that actually contains everything so just like before you can you know I'm gonna, do it on air. You can kind of send this data somewhere.

A

The browser also has an unhandled rejection, global error, our global rejection handler it has a little bit different signature than what we saw earlier. It takes like a promise event and on that event, there is a reason value that, hopefully, is an error object and you can report on it that way, and also what's really cool about. This is Firefox in the last couple months. Just added support for this, so it's actually relatively like newer thing, but now every browser supports all these global air tools, which is pretty cool.

A

One quick example: I do want to bring up that in node world. Listen, you! You run your whole environment. It's very easy! Just collect errors, throw them somewhere. Browser world is a little little tougher.

A

Here's an example of like actually using this on air handler where I'm loading a script with my example code and, very importantly, this is coming from a CDN, so I'm pointing you know, it's very common for us to publish static code onto CD ends these days where that's net liffe, I or something else, and if you do this this way, you might come into this problem where, if I, if I throw some code instead of getting you the stack trace. All this cool, like error, object that we were talking about. You don't get anything!

A

You just get script error. Okay! This is a problem that a lot of people run into when they're configuring. This so I think it's always like worth taking a minute to talk about it's very challenging because you, it is basically omitting everything so that that no object that have kind of highlighted in the output. That's the error object. So the browser has actually said, like you, can't see this, we're not even gonna show you what the air is in this situation and the reason it's doing.

A

That is because the same origin policy so same origin policy. Is you know this sort of policy that makes it so you know, windows and tabs, can't talk, you know, but you know communicate between domains.

A

You don't want to like leak information from your bank website to some other website, and this actually extends all the way to global errors, and this kind of makes sense, if you think about it, because what their fear is is that if you can load a script from another website and you're actually authenticated on that website, then it's possible that an error might be thrown from that website.

A

That contains private information about your account right, like you know, uncaught air user user been vinegar whose account details are one two, two, three, four, five, six, seven, eight nine! You know this is their password. That's obviously like super contrived I. Don't imagine that would happen, but that's it is a possibility, and so for that reason, if there's an error that would come from a script, that's hosted on another domain.

A

It actually gets sort of, like basically blanked out with the script error the way to get around it is you use cores if you're familiar with it cross-origin resource sharing? You have to do it in two ways. If you're requesting the script from a CDN, you have to set this attribute called cross-origin equals anonymous. That's actually a signal to the browser to say this is like the expectation is that this is sort of like a cookie. This domain, you can just request this. There's no session information, I, believe the browser literally doesn't send cookies.

A

If you, if you sort of like request a resource this way, if it's set up this way and then on the other side from your CDN or whatever, is you know, web server? That's returning this script, you have to actually declare that any origin can request this right. So you say, access control, allow origin asterisk or you can lock it down to a set of domains. That are trusted, and this is sort of like you know, it's almost like a handshake right.

A

The browser is saying I'm not going to request anything with session information, and the server is also saying. I have no expectation that there will be any session information here as well and once both of those things have to happen, then this example that I showed you earlier it'll work. You get to actually see errors that come from other domains, so just something to keep an eye out for so it's kind of like the end. What did we learn? That's a good question! I! Don't know you can use customerís, add meaning to failures.

A

If you're not already, you should keep in mind how stack traces are generated, because, if you're logging them, you might have a better idea now kind of like. Why does it have this shape? And where did the error like a Kurt from don't throw strings objects? Are there non errors because you'll find yourself in this very problematic situation where you don't know what's going on, and you can use global exception handlers to report errors? If you want to this is, of course, the part where I suggest that you shouldn't do that at all.

A

You should just use like a tool that does it for you, because it's really complicated and I don't have no time to go over the ways in which it is complicated, so century is.

A

This is kind of what we do and it's a source available software. So that's! Basically it's like fully permissible for you to run modify yourself. You can run on your own servers. It is on github on github.com, so I should get sentry. Sentry gives you cool error reports like this.

A

You know I usually don't mind pitching this because, like the whole, the whole idea here is that you can run it yourself and here's a kind of an example of that it exists.

A

We have a booth here and, if you're curious, to see what it looks like I'd love to talk about it. If you thought I nee, this was interesting. You want to learn just go a little bit further into you know: how does our century JavaScript library work? You could do go ahead and take a look at the source code over here. If you are curious more about the script arrow thing or you know you want to do your own air collection, I've written some blog posts that you can check out.

A

So that's it for me. I hope this was okay thanks. So much for being here now see Google.