This course is out of date and does not reflect our standards or industry best practices.
Transcript from the "Saving Error Reports" Lesson
>> Steve: So we can actually wire that up ourselves. The server that we wrote earlier also just has a way to receive these post requests and write a JSON file to an exceptions directory as well. So let's go ahead and leave that server running, and let's go ahead and just change a little bit of our code
>> Steve: All right,
>> Steve: So I wanna create a function called send uncaught exception. And because we're doing this by hand, it's gonna be a little more gnarly than what we got for free from electron.
>> Steve: So it will take an error, and we basically want to just go ahead and figure out a way to send it along.
[00:00:49] So we could, let's grab that product name and company name from that config we wrote earlier. So it'll say productName, companyName from the config and then we'll do, we'll bring on the request library which sends HTTP requests for us. You could use node fetch, you can use whatever you want.
[00:01:10] I'm just gonna use request because I want to.
>> Steve: You can use the native HTTP library if you don't like yourself. Go ahead and we'll say, console, info,
>> Steve: Catching error.
>> Steve: Just to know that we caught it.
>> Steve: Cool, and then we're just gonna send a post request,
>> Steve: You might not care about this, but you don't have to include it.
[00:02:09] This is the spoke so it's really, whatever we wanted in the properties, so on and so forth. So we can say the version. Now, the version, the best thing to do is get that from the package JSON, right? You have likely been updating in there. You don't wanna have to manually remember to do that, so in node you can actually require JSON files.
>> Steve: So go ahead and we'll get that package JSON in there. That's a dot dot, we need to go up in the directory. Cool, and so we can say that the version is manifest version cuz that'll be front of package JSON. Platform can be processed platform, right, just so we know what kind of things were your process type.
>> Steve: And we'll actually see what process type in a second. This is basically, did this happen in the main process or the render process, right? That's what process type is gonna be. That is actually and electronic specific thing. And you'll find out in a second, completely unintuitive to what you might think it is.
[00:03:19] Cool, and then let's just send some details about the error. So the error itself, we'll say the name is error.name, the message is the error.message. We'll probably see if we can get the file name that happened in.
>> Steve: So that's useful and then the call stack.
>> Steve: Right, we wanna know where it happened.
[00:03:50] Cuz if we get undefined, it's not a function. Cool, that happened somewhere, neat. I'd like to know where it happened. And we can also get the line number is error dot line number and column number,
>> Steve: Error dot column number, right? So this will send some pretty useful information to us whenever an error is thrown.
[00:04:19] Now, we do need to trigger this, right? We wrote a function, we need to actually trigger it as well. And so what we'll say is, if process type- Cuz main is more of a node process, while the render process is more of a browser process. Which is gonna be completely unintuitive when you see what happens next, but let's go with it.
[00:04:43] In fact, I'll actually show you real quick. In the main process, let's go ahead, just when it starts, we'll say, console.log, main process process.type. Anyone wanna take a lucky guess what we're gonna get?
>> Steve: That's right, the main process, it's called browser.
>> Steve: And renderer. So when you see me write the next line of code, I'm not making a mistake.
[00:05:24] [LAUGH] Right, the main process, the process type is browser and then the render process is renderer.
>> Steve: All right, cool. So what we'll do is we'll go back to that crash reporter and we'll say if process.type,
>> Steve: Browser, that means it's the main process, we'll say process.on. We'll do the node way of catching uncaught exceptions.
[00:05:51] Process on uncaught exception. We'll do that, send uncaught exception.
>> Steve: Otherwise, window.addEventListener for an error that bubbles all the way up to the window, we'll also send that. So whether it happens in a kind of node context, or if it happens in a browser context, we'll go ahead and we will get it either way.
[00:06:22] Cool, and then we'll do module.exports.
>> Steve: Sweet, now what we can do is we already have it there, we can also ask for it in the renderer process as well. So here, we'll do,
>> Steve: We'll have it in both places.
>> Steve: We'll go ahead,
>> Steve: We'll throw an error.
[00:07:16] And then let's go check,
>> Steve: All right, we'll just see what's going on here as well.
>> Steve: All right, fire that up.
>> Steve: We got an error there. Did catch the error this time, I think I just couldn't do it in the console.
>> Steve: You can see all of my uncaught exceptions are being caught as well, which is super cool.
[00:07:54] It gives you a way to be able to pull out stuff in. Now, and all that, writing it all to the fault system, if you just. That's not gonna be scale over a company like Slack as we're gonna write them to the and expressor. We're like what do you do on a server to actually deal with those reports is going to be unique to how you choose to handle it.
[00:08:11] But you can, theoretically, get crash reports from an absolute meltdown and then you can also get any of the uncollected exceptions, should you choose to. You can also do a little bit of introspection of, like, is this one I care about, and so on and so forth, right?
[00:08:24] This is just an approach to doing that, that you could choose to use, or not to use, as well.