[MUSIC]

Nothing in life is perfect.

This couldn't be more true than when it comes to humans and computers.

As developers, we can make mistakes in our code, things can go wrong externally,

like a server responding differently than you expect, or

even a user of the application may put in some incorrect input.

All these errors should be handled by our application.

Let's start by implementing a common type of error,

the errors emitted by asynchronous calls.

Many asynchronous nodeJS APIs give you an error event to listen to.

If you don't implement the error callback, bad things can happen.

For example your application could terminate unexpectedly.

Maybe it should terminate, but it's best that you add some programming to handle

it, even if it's just to return the error printout to the screen.

It will be a better user experience than showing a stack trace.

Let's create an error state by changing the URL to www.teamtreehouse.com.

Basically, there's no dot between www and teamtreehouse.

Save the application and open up the console.

Run, node app.js and the username.

And we get an error.

There's two important things here.

Firstly, it says unhandled error event.

This is on the request object.

We can write an error handler for that.

Secondly, here's the error message and a stack trace which isn't user friendly.

We can capture the error by implementing an error handler for the event.

Write request which is the request to the API,

dot on, meaning on an event.

And then the string error, meaning the error event,

and the callback to be executed when the error event is emitted.

This callback has an error object passed into it.

It's common for developers to put an E for an error as an argument for the callback.

But I'm going to use error for clarity.

We can log it out with the console.error and the error message.

All error objects have a message property.

I'm using the error method on the console because some terminal or

console environments display a different color for error messages.

So it's easy to see what's wrong.

Let's run the same code again with the incorrect URL and

see what happens this time.

Now we just see the error message getaddrinfo ENOTFOUND,

meaning the domain name can't be resolved.

This is less scary than a stack trace, but still is ambiguous for

the less technical among us.

You may decide this message is an appropriate message for

someone who is using this command line tool, but here's a challenge for you.

You could choose to create a better message for a user, but

we'll just leave it for now.

Let's remove the www

Save the file and make sure our code is still working.

Awesome, our profile information is still being returned.

Now there's another type of error that can happen, but

this is from a developer's perspective.

If we incorrectly pass in the URL when creating the request that doesn't

comply to the URL specification, for example if the protocol is missing,

an error will be thrown right away rather than being omitted.

When we run this,

we see a stack trace saying unable to determine the domain name.

Why is that?

Node's code design philosophy is if you pass in bad arguments to the node API,

it should throw immediately.

If you're passing good arguments in this case by passing in a valid URL.

But it will fail at runtime with an asynchronous error and

error event is emitted.

So when we pass a malformed URL like this with the protocol missing,

we need to use a, try catch block.

A try catch statement starts with the try keyword

And the code wrapped in a block you want to execute.

If an error occurs within this block it throws

an error in which you can catch the error.

And the catch block runs and

you have access to the error message.

Let's run this code again.

Now we get a cleaner message with no nasty stack trace.

Let's fix the URL before we forget.

And save and run the code again and it works fine.

We've handled two common error types, exceptions and emitted events,

and will take a look at some other areas where our application may fail.