 Okay, so I'm actually not going to be talking so much about the product though of course there is an element of the product which as well But I'll be talking more about about how to handle Errors in JavaScript in general, you know people hate product which is I would hate to say So I So I'm going to talk about how to handle errors in JavaScript But before that my name is Rakesh Pai Rakesh Pai.me My Twitter is Rakesh314 And I'm sort of like a hipster, right? I've been doing JavaScript before it was cool But that's how it is, right? I'll very quickly rush through the purpose of catching errors But I'm sure everyone knows why it is important to know to catch errors JavaScript is very different from other programming languages JavaScript so you know if you're coding in PHP or Ruby or Rails or whatever You can you can freaking compile the OS the way you want it right with the right thing In JavaScript, you don't have that. You don't have that luxury. Your code is running in the wild It's running on environments that you have no control over in operating systems and setups that you have absolutely You cannot predict beforehand. JavaScript is very different from other environments There is there is this I would call it a three-dimensional grid of possibilities, right? There is the operating systems There's the browsers and the browser versions right so it's a three-dimensional grid within which anywhere your errors can occur and you You have absolutely no control over Errors when they happen are locked to your end users console So so when errors occur, they are locked to your end users console, which is absolutely useless to you as A programmer because those errors are essentially lost. You don't find out about such errors, right? and Let errors occur your users are not going to complain to you You know users are going to leave your site because you complete the websites are working your sites or not You know, they are not they're not going to you know It's not a nice word where people are going to file a bug report go find very about that's not how it works, right? So so that's so it's important to find out what's going wrong with your website and and hence It's important to catch errors The best case scenario is let's say your ad network or something that breaks down and you get this little You know done work with errors on the page and your code still continues to work, right? That's the best case scenario But you know in the worst case scenario Your app blows up So so yeah, so when JavaScript fails, it takes down everything You don't want to be in that situation Right so Gonna go over a bunch of mechanisms of catching these errors Mind you'd like to patch to this one is catching errors in the second is reporting the error to some service So that so that you can do fancy stuff with it I'm not going to talk about reporting the reporting better the posting of the error bit so much That's rather trivial. You figure out a mechanism by which you can post that The difficult bit is how do you catch the error and that's what I'm going to be talking about Because because we are you know of the computer science better than you know that we have to be how to act like we have a very scientific You know my heart So I'm going to establish a bunch of criteria This this criteria. This is my opinion about how about how Or what you should be looking for in an error reporting system your opinions might be different and that's fine Performance is very important to me I do not want to compromise on performance either at runtime or at low time Right time performance is a lesser of a concern because our engines are getting so fast But but load time performance is very very important and no account should there be a load time I Could have you don't I spoke about this in last talk as well I could have probably changed I could have called you something else by reliability What I essentially mean is that you should not be taking a hard dependency on the system So in case the system for whatever reason breaks down your app still continues to work and to me I'm calling that reliability. I don't have a better word for it But if you have please let me know but that's what I'm calling reliability here that you don't take a hard dependency on the system right The implementation effort should be little if the implementation effort the ongoing implementation effort is very high to keep working with an Error reporting system. You're going to stop working towards making data reporting system work eventually So, you know implementation effort has to be as low as possible These three things to me are the most important things When I'm trying to consider which error recording system to use If there is going to be a compromise either on performance if it requires that I'm going to take a heavy dependency on the system Or if there's going to be a lot of ongoing effort for me to continue implementing it I'm going to throw such a system away because it does not work, right? If any one of the systems come across Have these characteristics. I'm going to throw them away other than this. There are a bunch of other good to have And that is that I should be able to if I can get rich details about the error things like stat races You know all that kind of stuff and that would be awesome If it has got a hundred percent coverage of all of my errors are covered by by by this by the error That's awesome. So for example If you have an a href one click equal to something, right? Is that going to be caught by the system if it can create, you know, if it can't if it only does You know external JavaScript, that's not too bad either. So, you know coverage coverage is one of the factors Simplicity, of course, I like simplicity a lot and there's this great value to simplicity So, you know, if it's going to simple it obviously become better And browser support goes without saying you're talking about clients either or so, you know decent brother support is necessary So we're going to come with a scorecard, you know, like I said, we have a look scientific So that's the top three performance reliability and effort And I put your stars next to that because I don't find any other unique points You know, these are the three most important things that I would care about and these are, you know, other things that So, so let's get started. There are about six or seven mechanisms will be raised through all of them It's you know, it's hopefully not too much So so the first mechanism is to add tri-catch blocks manually to your code, right? It's beautiful Who likes to add tri-catch blocks? If anybody here is familiar with astrophysics, there's a system called Specification records. It's a Black hole and then there's the event horizon of a black hole and a black matter enters through the event horizon It gets extra there are opposing gravity forces on it gets excluded and it gets stretched and broken into little pieces And you know, it's a stream of atoms that's flowing. So I show you how tri-catch blocks work like that, right? So so let's take this case of a very simple function Where what it does is it waits for page load to be ready and then when a button click happens It's going to alert the next sequential number in the scene, right? So a simple piece of code now Let's say that I want to add tri-catch blocks to this and he guesses about how this will work Turns out This is how it turns out right because Because of the nature of joust When I have done when I define this one function the outermost function this stack is now is thrown away because the execution of this a sentence is done Right at some point in the future the inner functions going to execute that's going to have its own stack Right and so now I have to have the outer tri-catch because the outer tri-catch stack has already enrolled It's gone, right? So now my inner code has to have its own tri-catch Which is over here. So I've got the outer tri-catch then my inner tri-catch Then of course the button click happens at some and specified time in the future that will require its own tri-catch, right? So so there are there are Looking at this trivially, it's hard to say where all I will need to add tri-catch blocks Now these functions here are a sequence functions if the functions were synchronous functions Then I don't need tri-catch because the other tri-catch will work with the same call stack, right? But since they are racing functions, I will need to have a tri-catch blocks around each of those racing functions I'm hiding away this detail in the poster and I'll come to that in a second But but you can see how how complex it gets very quickly Yeah, it's hard. I don't know if I was supposed to do this dude. I'm not going to do it next season This is painful, right? So so let's look at the scorecard and come to performance in a second Relativity is great because you are not taking the heart There's no system so to say to take a heart dependency or so Effort is not low at all. So I'm counting out effort and really because I said the top three is what matters I've got a negative over here already. I can throw the system away, but for completeness There is I get rich errors. So each time you get an error object, right? Which is what you were getting last time and that cross-draw the concerns and all of that But keeping all of that complications aside generally if you get an error object There is there's a great deal of data that you can get out from that So so so yeah, so rich errors are possible thanks to that I'm going to say coverage is bad because because your coverage is manual You have to remember to add tri-catch blocks everywhere So I'm going to generally say that coverage is bad unless you are diligent enough to make sure that everything has been covered It's simple, you know, it's not to configure a system. The code is complex But it's it's not easy. It's not complicated to reason with the system. The system is really simple And browser support is great No support is everywhere the tri-catch blocks support and tri-catch blocks have been supported for donkeys years in That's good. I said I'll come back to performance performance depends because Right here. I've defined the poster function. I'm assuming the poster function is available Now this this poster function is basically going to take the job or going to the job of collecting the error object And then posting that to a server somehow Those details apart The fact is the function has to be defined for you to use beforehand And there are several ways in which you can make this function available within the scope of the execution scope One is of course that you include a script that is going to have that's going to find the poster function Right simple enough. The problem is that is now going to add a Network request to your page and hence your page load is going to slow down by that much great because now you're going over the network To fetch a file so that's going to slow it up. That's going to make a performance deteriorate a bit How you try turning it off and on So So another way to make another way to so so you know external requests are not a good idea Let's say that you decide to inline the code Now this could be problematic depending on how big the Poster function itself is if it's too big inlining, it is not a good idea And you know if you do in line it anyway, you will have this on several pages How do you manage any changes that might happen to it and so on so, you know, it depends on which approach you take It would be either fast or slow We'll come back and address this towards the end of the talk But for now, let's just say that performance depends on which approach you take Now there are Since manually adding Pricache blocks such a pain you could consider adding them automatically There are a couple of ways in which that can be done There's a way in which so let's say that you can have a build script, right? That is going to do this for you The way it will work is that during build time it will look at your JavaScript code load that into an AST generator Look at this syntax tree now and within that syntax tree find out which are the function calls and to those function calls Append Pricache blocks to them, right? It's possible to do this. It's painful, but it's possible to do this It's fairly complex the build system is complex. Of course once your build system is ready Using it is rather simple. You just write code as usual and then your build script takes care of it, right? But building the build system is fairly complex It then requires static analysis of the code if you're scared of looking at things like ASTs that this is not for you And it can reduce its own bugs, of course because because you're dealing with jobs at the back level So performance again depends for the same reason because poster has to be available somehow But that said reliability is great because you are not having at runtime at least you're not having a dependency on an external system You know your build script will either work or fail and that does not affect your site itself, right? So so reliability is great Effort is low because you just continue writing code is normal Of course there is the one-time effort of creating the build script itself which which I'm not counting over here Because that's a one-time effort. So it's not an ongoing effort. So I'm going to come that out Errors are great. Coverage is mostly great And I'll come to what I mean by mostly It's not a simple system because you are you're writing code in one place and what you are ending up shipping to the user is another thing All together. So, you know, it's there's no sort of it's hard to map that one to one So it's not really clean Browse support again is great because it's just using tri-cache blocks of work Coverage is good mostly because you cannot cover inline code at all with this, right? So unless you're thinking about passing your HTML to AST generator by looking at your HTML script ads and so on is this painful, right? So coverage is only just mostly good But that's that's that's not bad at all now now out of the three that I mentioned You can make performance good. So you've got the remaining two green there Which is one of the best methods really, you know of all the methods that I'm going to discuss This is one of the best methods. I Recommend that if you are really serious about catching your errors consider this of course It's not for the faint of heart because you have to build your own AST parser, but but This is this is not this is one of the best methods out there Right, let's move on quickly This is these are internal tools. So, you know, the best of being an internal tool it depends on Company to company. I don't know any example that she's Right, but but we come to variants of that very quickly and so we find out There are there are mechanisms by which you can so there are services that are available, right? You do not believe this kind of services that are available That's crazy There are services that are available to which you can give them your JavaScript file And they will give you a file that has got tri-cache blocks Would have thought that But but there are services that are available that do this. So what you do is that you instead of including Your JavaScript file directly from your web server You include JavaScript file from their proxy instead What what happens is that your script source is pointing to their proxy Their proxy will then in turn make a request to your web server Pick up your file add tri-cache blocks to your code and then show down the tri-cached code To your client, right? So that gives you Tri-cached code into the client, right? So that's that's awesome. Um You end up you do end up taking a heavy dependency on the proxy. What if the proxy goes down? You know, that's that's that's a solid concern that you heard me worried about Um You know, I can still into this one box because you're still looking at ASK But this is the lesser of a concern because we're going to say that these guys know what they're doing They're the guys who shift the proxy so they know what they're doing Um, but yeah, you do end up taking a heavy dependency on the proxy So the scorecard here looks like this performance tree depends for the same reason Reliability has gone down obviously because you are your code The how well how quickly your code without or even the very running of your code is dependent on on their proxy Anything else is mostly fine. It's still not a simple system, but it's mostly fine. But but you know a big red over there We don't want that So a new service launched by public or by combinator funding and all that that's awesome. Uh, that does something very similar Where what they have is that you know, they try to mitigate the problem of the reliability issue that we had the last time And you know, they say that in case the proxy is down what we will do is we will reroute the traffic to your own web server So so your code continues to run fine, right? Brilliant in concept, but then uh, we quickly find out that So the way it works is that on the client side There's no other way to do this. It has to be done from the client side If you think about it is that on the client side, they introduce a script loader for you So they ask you to load this js file And what this js file does is Oh Right, so it adds a script loader and what the script loader does is that when there is So the script loader what it does is that it it tries to connect to the proxy And if the proxy can give code down to the user then that's great and uh, uh, everything works as usual If the proxy cannot if if the code cannot connect the client cannot connect to the proxy Then it will now try to connect to your web server So it tries to connect to the proxy discovers the proxy is down Uh, and you cannot get code from the proxy then it sort of routes the traffic to your your web server instead So that's how it works. I call that proxy to the failover. I don't have a better name for it But you know, uh reliability obviously improves because now you are not dependent on the proxy being up Your your app can take care of the load as well. Uh, but performance obviously deteriorates and that's because uh You know for two reasons number one is the worst case scenario is when their proxy is down Uh, you have to connect with the proxy first to discover that it is down There's you know, no other way you can do it and only after you discover that it is down You're going to connect into your web server, which is at least one network request extra that you heard of make Uh, just so that you can your app can even get bootstrapped, right? The other reason which is the far worst reason is that you are now forced to use a script loader Which is a blocking network request for all of your users at all times, you know, you there's no other solution So, uh performance is definitely going to go down because that's uh, yeah So it needs a script loader and and that is at least its own additional network request So i'm going to give performance a batch core over here for sure There is no way you can fix performance, but reliability has fixed itself. So, you know, that's a good thing Otherwise anything else is fine There are companies that do this as well What they do is that you add that script tag to your page and then they will start playing with your browser methods itself So rather than adding tri-cache to your code, they will add tri-cache to your run type. So, you know, like for I'll show you a quick example Uh, and this is a very simplified implementation here. Uh, I hope the port is available But what it does is that for example, I'm just taking one function over here called document dot add event listener Which is very familiar to everyone And i'm cashing that into a into a variable here and i'm creating my own document dot add event listener now Which overrides the original document dot add event listener Where what i'm doing is that i'm basically calling the old document dot add event listener Except that the handler has now got a tri-cache around it handler that was passed it So i'm returning the same signature as as the original document dot add event listener But uh, this is my code now. This is not the browser's code And i have added a tri-cache around every handler that's being passed it right any question is this clear any questions about this It's a little complex if you are not used to this Sorry To set time out so you can do this to a bunch of things you can do this to uh, yeah You can do this to native events. You can do this to set time out There are things that you can't do this to you can't do this to uh, say a jack's pulse right because you got ready state Changing over time and stuff. So you can't do this to a jack's pulse But but yeah, there are a couple of things that you can do this to um So so yeah, this is one more approach that people are doing now. This is a very simplified implementation. I need go ahead So will this tri-cache blocks will be applied to any inner functions or closures? Those won't get this tri-cache dot. Yeah, you're right So so inner functions will not have this unless your inner functions are using dom methods to become asynchronous In the sense of you know Like like the example that I showed you where where there was the jQuery example of button click and all that that will work Find this example because you're using browser methods to To do your async operations Yeah, what is sitting so on load will definitely be wrapped but then you would also need to wrap Yeah, so on load will definitely be wrapped But you will also need to wrap things that is happening inside of all So you might be setting up events inside of on load and so on and so forth, right? So you need to wrap those as well internally, but but yeah, largely this works now This is a very like I said, this is a very simplified implementation. I'm only over writing one event over here Which is called document dot add event listener. It's operating only one object, which is a document object You will have to do this for every single node. You will have to do this for things like set time out in set interval You will have to do this all over the place Now you would think that this is this is easy to do, you know, I can just play with prototypes of of Commonly known objects like node or element or whatever Turns out you can't play with prototypes of native objects and internet explorer and older versions So there are other hacks you have to do where you're keep watching the dom and every time there's a dom change Figure out which was a delta that changed and then do that you have to add methods. It's painful, right? Very very So here's a score that performance I'm going to say is bad and the reason I'm going to say performance is bad It's not because there's a lot to be done But you know, I'm going to assume that that is fast because engines are fast But I'm going to say performance is bad because you have to do this before the rest of your code runs, right? So you have to do this before any of your before your app actually starts. So, uh Can you just tell me what has to be done So so I'm going to say performance is bad because you have to do all of this stuff before Uh, the cache loads. So So that's going to be a network request that you're going to send out from your machine From the user's box that is going to do all of this stuff first to your page And only then can the rest of your app Start loading. I mean if you already attached events and so on beforehand, uh, you cannot add tri-cache Tri-cache blocks to them once they have already been added, right? You have to do it before everything starts So so, uh, uh, that's why I'm going to say that this is bad The last one here is windowed off on error And what windowed on error the way it works is that it's basically an event like windowed off on load or whatever you can assign A listener to it. Uh, it gets three parameters message line number and file Number and file is the file the line number in that file at which the error button gives you a message Now honestly, this suddenly looks very beautiful to me because uh Every time so every time an error occurs this thing gets fired and you can you can now cast the error over here, right? This looks beautiful because this is not marking with your code. This is not marking with your runtime You know, this is not doing any of the fancy stuff. Uh, it's sitting by itself in one corner completely externally So so I I like this approach a lot The downsides are that you do not have access to an error object because all you get is these three parameters So you don't have error objects with you. Uh, so errors necessarily can't be reached. You can't get stack traces for example, right? And the problem is that by the time this windowed off on error has been called the stack has already unrolled Uh, so even if you don't explicitly get a stack trace You cannot manually walk your call stack and try to build your stack trace yourself because the stack is not available It is already unrolled, right? As a pro though it is gets simple to implement this You know, that's all the code that you have to write and you get you get errors by yourself, right? Um, so here's a score by performance again depends reliability and effort have gone up Uh, so after the build system base thing that you are talking about this is really the best looking system over here Uh, so so while building an exception I decided I decided to give a hard look at this and see if I could package this into a nice thing and you know make this Make this uh, uh worthy enough of consideration and you know, uh, make this into a service that's easy to use Uh, and I was fortunately able to do just that But before that here's Yeah, thanks for playing. So, uh, this is this is how everything looks so far Uh, as you can see in these top three rows Uh, only the build system and the window dot on error has got Green marks whereas everything else has got a red somewhere or the other within the top three Uh, so so that's basically it you either implement your own build system Or you use window dot on error to get the benefits of performance and reliability and and maintaining your effort without time Uh, now now obviously over here Uh So post error, right? This is something that we have constantly avoided And I said I'll come back to this So how do you make post error available in your page? Uh, in a fashion that does not block your page load was one of the challenges that I wanted to fix And though I talked about this in detail in a previous talk that had to do with with, uh, Third-party JavaScript, but this is basically what I'm doing is that I've got an array And every time an error occurs I'm pushing data into that array Right, this is the snippet that I give you the so when you log into error section You create an account your snippet is basically doing this. It's an array into which I'm pushing data as and when I get errors Meanwhile at a later time in fact so late as after page load I am loading the code to process this array and then post that data to the server, right? So so now the benefit is that I can do this in line. So this is snippet that I give you You copy this onto your page and there is absolutely no performances that you will get because of this because all I'm doing is populating an array There's nothing else. I'm doing locally on your on on the user's machine Meanwhile, apparently in fact, I do it later so late in the page load cycle that your code is not going to get affected at all Your resources will continue to load as normal I will then load the code up that is going to process this array right and So there is no load time performance it and you also don't take a hard dependency in case my code does not load for whatever reason The worst that happens is you want an array that's populated, right? That's not flush That's the worst that happens does not get worse than that. So it's highly highly reliable because of that So so that's an exception for you. It's high performance by design It's highly reliable by design for the reasons that I just explained It catches all errors. So so the coverage here is the best Because it catches errors that happen inside on-click handlers It catches errors that happen in inline JavaScript that sits inside your html It's crazy the kind of coverage that this gets is crazy It catches errors that happen inside ad networks It catches errors. Did you know that google bot executes your JavaScript? I can show you I can show you errors that have popped from google bot. It's freaking crazy, right? So it catches all kinds of errors, right as a as a As a con, there are no stack traces that are available You know because of the approaches that I told you I cannot get stack traces over here Except in IE now IE is a funky case where I'm able to build a pseudo stack trace by walking the call stack because when window error is called The the stack will actually not unrolled in IE which is very interesting So all of a sudden now I have possibilities over there So I can now walk the call stack and I can you know find out which were the functions called and so on So I do that in the case of IE. So you have stack traces in IE Uh, you know I'm slowly if you notice I'm slowly moving towards the product which but you know, I'm doing that. So other features are that This is duplicate the duplication detection, which is you know, you get You have a million users using your site. You cannot give you a you know, these are the million errors that you've got right? You're gonna say So so I need to sort of make that into a smaller list, right? So I do that by by detecting duplicates very well So I say that the error has happened in clone 16 and 17 and 14 and 13, right? This is the one error that occurred seven times, you know, so on and so forth, right? And yeah, it goes on to add a bunch of metrics about errors and show you a quick screenshot of that. It's very interesting And it reads out errors that you don't care about. So for example, if google analytics, you know, you probably don't care about it This catches errors in google analytics, man. It's crazy. Uh, you know, for example, facebook did not Your facebook widget did not load on the light button. Uh, you know It don't work. Uh, you probably don't care about that. So I was like that A little bit of marketing talks is one quick slide Is that it's being used by several big internet brands. Uh, I unfortunately don't have the liberty of naming them But trust me on this, uh, big internet brands that are using this five million errors so far It's only been in existence for about four months now, but five million errors so far These are internet brands, right? The internet website is what they care about and the website is their product And there are five million errors that I've got over it. So, you know, you can imagine the scale of this As much as I've said that the library is not a problem, you know, I've never had it on time so far So sign up. The slide is already starting close beta anymore. It's free. Uh, the client is free. So, you know, give it a spin Tell me what you think Quick set of screenshots Of the app I've written away some details so that you don't see, uh, you know So that, you know, people are not implicated Uh, and this is what an error report looks like. It's got a bunch of details about which, which error, which, but also it happened and so on and so forth Uh, that's it. Uh, it's built for those who are interested. It's built with Node and Mongo. So, you know, uh, it's a JavaScript stack My, my shell script is certain in Node. I'm also, I mean, I, I love that word Uh, so give it a spin. Erastruption.com. I had Erastruption as a Twitter handle Uh, that's it. Thanks a lot. Thanks a lot already, miss What's the performance guide? We never got on as a The performance comes from Windows. We're not on here. There is no performance. I mean, there is, there is, there's whatever runtime performance comes from here But I don't know that much. It's very minimal means you let the performance depend on you Oh, that is because of the way the post error function is being introduced into the page. It does not, uh, otherwise it's, it's, it's not embedded Yeah, why? What's the browser support for Windows or not on it? Oh, great question. So, uh, so, the browser support for Windows or on error is, is not as good as the browser support for trycatch blocks Uh, so, for example, so all your popular browsers are supported. So, your Firefox, your IE, your Chrome Opera, the latest version of opera now supports, uh, trycatch blocks Uh, older versions did not support it. So, on error is not supporting, I guess. I, no, Windows or on error is there in the latest versions of opera. It is not there in older versions here, right? Uh, mobile browsers did not support this until iOS 5 being the first, uh, mobile environment that supports, uh, Windows or on error. So, in your iPads and your iPhones now you can catch errors, uh, with Windows or on error Uh, but, but yeah, there are older browsers in which it does not work. So Firefox 2 and older, it's not supported Interestingly, all of IE is supported. IE is the one who pioneered Windows or on error. So, it's, it's supported in all of IE Uh, it's not supported in older versions of Chrome. I think Chrome 11 and before is not supported But, Chrome is not so much of an issue because people can be upgrading it quickly Uh, so yeah, so most, most popular environments are supported. There might be esoteric browsers that are not supporting Windows or on error Do you do something for browsers that do not support it? Not at the moment, no, uh, but I have plans coming up very quickly to, to fix that. There are a couple of ideas that I have Because I still think that proxy approach is not that bad if you do proper network re-routes Uh, yeah, fair enough, fair enough, but then there is, there is a performance cost that comes You can, you can do that as a, in case it doesn't Right, right, right, I, uh, yeah, in any case, I do plan to incorporate, uh, mechanisms for browsers that don't support Okay, could you repeat this question? Yeah, his question was, uh, that, what, what about browsers that do not support Windows or on error? Will it be, uh, will it not work in, in those browsers? Or are there any other mechanisms available for them? So error section currently doesn't, but I have plans to do that About adding, uh, these, uh, errors, uh, adding, uh, trycatches to DOM methods, right? I don't understand the performance cost So, uh, the question was adding, uh, trycatches, uh, trycatches to DOM elements, what is the performance cost? The, the performance cost is not the runtime performance cost. The performance cost is that this has to be done beforehand And hence requires you to introduce a script tag that's going to do this Now, uh, if you look at people who have, well, code that is already doing this The code size is somewhere in the region of 50k, which is, which is like, you know 33, 66 percent larger than jQuery is, you know, it's, it's very big Uh, so you have to download that code from your server and you do that in a blocking fashion because You necessarily have to do that before all of your other code runs So that is the performance cost to do, thanks, thanks a lot If you have any questions, repeat it