Introduction to Node.js, v2 Errors and Async Await Q&A
Transcript from the "Errors and Async Await Q&A" Lesson
[00:00:00]
>> Any questions on errors and error handling in Node js? Good question. How are we able to use the process without importing it? Well, that's because process is an actual global variable inside of node js. It's one of the globals that I talked about here he goes to the global slide.
[00:00:18] I think I've talked about process here. Yep, so process is given to me for free. It's part of the global space, just like the keyword import is there just like the keyword module is there. Process is one of those things that you get for free. I don't know how node determines what should be internal module that you have to import versus what should be a global that's just there, but they decided that process was gonna be a global that you don't have to import.
[00:00:45] Whereas fs has got to be something that you do have to import. I think there's like a level of like importance, process is very important. I would imagine there's really not too many apps you can use without building, without interacting with the process some point. So I think they felt that was so important that it should have been a global and not something that should be imported.
[00:01:03] Whereas fs yeah, you could probably make a bunch of apps without ever using fs. So we'll make that import a module that you have to import. I'm guessing I don't know, the thought behind that
>> What's the difference between an error and an exception?.
>> There is, the only differences is that an error can cause an exception.
[00:01:22] So if you have an error, as in some discrepancy, some miscommunication in your app, if you throw the error that raises an exception so an error alone is just an object. It's just an object about some metadata like here's a line of code, here's where it broke, here's what happened, the type of error, nothing happens until you actually throw that error, which causes an exception built into JavaScript.
[00:01:48] That's just how JavaScript executes. So yeah, you can think of an exception is like an error that was like escalated to the highest level. It's like getting a customer service and like speaking to a manager, that's. [LAUGH] That's an exception. Where's the errors you just calling and complaining in the first place.
[00:02:02] So that's the difference. This is gonna come in handy. So I want you to remember the error stuff. And the reason I wanted to talk about this one is because this one really messed me up for a long time, especially async errors. I just did not understand it.
[00:02:16] Like I went back and looked at some of the code that I wrote in like 2014 and I was just laughing like. [LAUGH] I wasn't handling anything. I wasn't doing anything like if anyone just mistype one word, my whole app will crash and I just didn't, I didn't even know it back then.
[00:02:29] So, yeah, pay attention to the errors. Luckily for you, most of the frameworks and abstractions at your use will have really nice built in error support hooks that you can tie in to that makes it so easy to format things and do stuff. But yeah, take advantage of that.
[00:02:45] Watch errors and be cautious. The question was, is await blocking a thread? And if so, why are we using it versus just using synchronous? That's a really great question. And the fact that you asked that question tells me that await is doing its job. It gives you the illusion that is blocking a thread.
[00:03:00] That's the whole point. The whole point is that it should feel like synchronous code. It should feel like It is blocking and nothing else is happening, but that's not actually what's happening. If you were to look at what await gets transpiled into, it actually gets turned into what's called a generator, which is like, you can think of a generator ,it's like an async four loop, basically.
[00:03:25] So it's the equivalent as if you basically put the code that comes after the async await. inside of a dot then callback, or inside of a callback of asynchronous function. It's the same thing functionally, but visually it looks like it's blocking because async await was really only created to solve a visual problem promises, or in fact, callbacks already solved the functional problem of like, well, I want this code to run after some asynchronous thing.
[00:03:54] callbacks solved that years ago. Promises was an attempt to make it visually better. Instead of having all these nested callbacks. Thanks to node and databases. We had these you never see this pattern on the front end you would never see 20 nested callbacks on the front end never on async because you didn't make 20 API calls on the front ended and 20 event handler calls nested in each other.
[00:04:15] It wasn't until when time come people started interacting with other APIs and databases where we saw this crazy async patterns where promises were invented to keep them somewhat flat. You can do a dot then followed by another dot then and another catch and it was somewhat flat just one level deep.
[00:04:30] But it was still wasn't top to bottom cuz you can put something after the dot then and that was still execute first before the previous dot then so it was still not really solving that problem for people. Understanding to read from top to bottom, like other languages that are blocking that have threads like Python or something like that.
[00:04:47] So async await was created to solve the visual problem of okay, you're just gonna read it from top to bottom, but it's still gonna work like callbacks, okay, it's still gonna work in the back. In event loop is just that this code has been added to the callback.
[00:05:01] So yes, it does look that way. But no, it is not blocking.
>> So along with that, if you're awaiting something, can you continue to process other things?
>> No, cuz if you put await in front of something, the next line won't execute until read file comes back with a result or throws an error.
[00:05:26] It won't even be read and wanting to be seen. Because it's the equivalent of putting it in a callback. It just won't happen. So no you cannot continue to process something that defeats the purpose of the await. If you want to continue processing something while something else is happening in the background, then you won't use async await you will use a callback or you use dot then.
[00:05:49] And then now you can have code that reads from top to bottom but then jumps back up when it's done which is fine. Like it's not hard to follow that code until it gets crazy. But async await tries to get rid of that as much as possible. Me personally, I use async await for everything because I think it's amazing.
[00:06:06] Like it really, I write code in a lot of languages and this just makes it feel like everything else in my opinion, but it also keeps Java scripts asynchronous event loop base. The features that are like it still has that part but it makes it look like everything else.
[00:06:20] So it's less confusing for me. So we last left off talking about Error handling in Node.js and the different ways that you can go about doing that. I emphasize just how important that is when it comes to deciding on how and when you shut down your app depending on what errors.
[00:06:39] And that's gonna be more obvious when you get into building things like servers, especially servers and other types of applications that require user input because sometimes their input could cause an error but not a show stopping error game stopping error that should crash your application. So that's why that was important.