Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Often a lot of the APIs give you an "error" event to listen to. In this video we'll handle this type of error event.
Update
Adding www to the URL in the GET request on line 15 no longer results in an unhandled error event. Now it causes a SyntaxError: Unexpected end of JSON input to be thrown instead. To generate the unhandled error event and practice the solution demonstrated in the video, you can substitute abc for www.
Documentation
[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
You need to sign up for Treehouse in order to download course files.
Sign up