Handling the Error Event in Node

[MUSIC] 0:00 Nothing in life is perfect. 0:04 This couldn't be more true than when it comes to humans and computers. 0:06 As developers, we can make mistakes in our code, things can go wrong externally, 0:10 like a server responding differently than you expect, or 0:15 even a user of the application may put in some incorrect input. 0:18 All these errors should be handled by our application. 0:22 Let's start by implementing a common type of error, 0:26 the errors emitted by asynchronous calls. 0:29 Many asynchronous nodeJS APIs give you an error event to listen to. 0:32 If you don't implement the error callback, bad things can happen. 0:36 For example your application could terminate unexpectedly. 0:40 Maybe it should terminate, but it's best that you add some programming to handle 0:43 it, even if it's just to return the error printout to the screen. 0:47 It will be a better user experience than showing a stack trace. 0:51 Let's create an error state by changing the URL to www.teamtreehouse.com. 0:56 Basically, there's no dot between www and teamtreehouse. 1:03 Save the application and open up the console. 1:08 Run, node app.js and the username. 1:11 And we get an error. 1:18 There's two important things here. 1:20 Firstly, it says unhandled error event. 1:22 This is on the request object. 1:26 We can write an error handler for that. 1:28 Secondly, here's the error message and a stack trace which isn't user friendly. 1:31 We can capture the error by implementing an error handler for the event. 1:39 Write request which is the request to the API, 1:44 dot on, meaning on an event. 1:48 And then the string error, meaning the error event, 1:53 and the callback to be executed when the error event is emitted. 1:59 This callback has an error object passed into it. 2:25 It's common for developers to put an E for an error as an argument for the callback. 2:29 But I'm going to use error for clarity. 2:34 We can log it out with the console.error and the error message. 2:37 All error objects have a message property. 2:43 I'm using the error method on the console because some terminal or 2:45 console environments display a different color for error messages. 2:48 So it's easy to see what's wrong. 2:53 Let's run the same code again with the incorrect URL and 2:56 see what happens this time. 2:59 Now we just see the error message getaddrinfo ENOTFOUND, 3:02 meaning the domain name can't be resolved. 3:08 This is less scary than a stack trace, but still is ambiguous for 3:11 the less technical among us. 3:15 You may decide this message is an appropriate message for 3:17 someone who is using this command line tool, but here's a challenge for you. 3:21 You could choose to create a better message for a user, but 3:25 we'll just leave it for now. 3:29 Let's remove the www 3:32 Save the file and make sure our code is still working. 3:38 Awesome, our profile information is still being returned. 3:44 Now there's another type of error that can happen, but 3:49 this is from a developer's perspective. 3:52 If we incorrectly pass in the URL when creating the request that doesn't 3:55 comply to the URL specification, for example if the protocol is missing, 4:00 an error will be thrown right away rather than being omitted. 4:05 When we run this, 4:13 we see a stack trace saying unable to determine the domain name. 4:14 Why is that? 4:20 Node's code design philosophy is if you pass in bad arguments to the node API, 4:21 it should throw immediately. 4:27 If you're passing good arguments in this case by passing in a valid URL. 4:29 But it will fail at runtime with an asynchronous error and 4:35 error event is emitted. 4:39 So when we pass a malformed URL like this with the protocol missing, 4:41 we need to use a, try catch block. 4:46 A try catch statement starts with the try keyword 4:49 And the code wrapped in a block you want to execute. 4:56 If an error occurs within this block it throws 5:20 an error in which you can catch the error. 5:25 And the catch block runs and 5:33 you have access to the error message. 5:37 Let's run this code again. 5:48 Now we get a cleaner message with no nasty stack trace. 5:52 Let's fix the URL before we forget. 5:56 And save and run the code again and it works fine. 6:05 We've handled two common error types, exceptions and emitted events, 6:10 and will take a look at some other areas where our application may fail. 6:16