Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial![](https://ecs-static.teamtreehouse.com/assets/views/marketing/shared/community-banner-white-47072046c51352fe6a69f5e691ff5700b28bb11d45197d7bdf066d9ea3f72d0c.webp)
![James Barrett](https://uploads.teamtreehouse.com/production/profile-photos/3674042/micro_jamesbarrett19th.png)
James Barrett
13,253 PointsCould someone clarify what Andrew is saying here?
4:27 - 4:46: 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.
Could someone clarify what Andrew is saying here? I am getting slightly confused. So are we passing a 'good' or 'bad' argument by providing a URL which is: 'teamtreehouse.com/[usernamehere].json
It seems to be a 'bad' argument, because, as Andrew states "it should throw immediately", which it does! However it's almost as if he is contradicting himself by saying "if you're passing good arguments in this case by passing a valid URL"
I'm just asking so I can understand where I can/should add try and catch blocks in Node.js code.
Maybe I am over-thinking this. Any help would be great!
Thanks, James.
3 Answers
![Farid Wilhelm Zimmermann](https://uploads.teamtreehouse.com/production/profile-photos/5686782/micro_IMG_20170731_202555_800.jpg)
Farid Wilhelm Zimmermann
16,753 PointsWhat Andrew is meaning is that some errors (such as the one regarding the "bad" url protocol) are fetched by the Node API immediately , which then throws an exception that contains the stack trace.
To avoid this immediate "crash" of our program, we need to make use of the try/catch blocks. This lets us not only print out a readable error messages, but also prevents our programm from crashing when an exception occurs.
Try/catch blocks are used extensively in other programming languages to handle exceptions. Even though javascript provides us a nice and clear way of handling errors(by listening for error events using .on), there are still some edge cases that require us to handle exceptions with a try/catch.
The main takeaway is, that a try/catch block lets you write code that won't stop execution as long as the exception is handled!
![Tom Geraghty](https://uploads.teamtreehouse.com/production/profile-photos/1155052/micro_thisone_copy.jpg)
Tom Geraghty
24,174 PointsI believe he was trying to vaguely introduce the idea of different error complexity and handling. An error in your application's logic is catastrophic and shouldn't be allowed into production (but we all know it does happen as we've had programs crash unexpectedly).
However there are also errors that aren't a problem with how the application runs or it's logic but rather something else gets messed up along the way. The most common of these is a failure to get the resources we were expecting. This type of error is outside the hands of the developer at production time so it needs to be anticipated so the program can "fail gracefully" and let the user know why it happened (and what steps should be taken).
An example would be a request for pictures from the Flickr API. Say you have a photo blog and want to display photos dynamically from Flickr on your personal blog. So you have a request get the pictures from Flickr and then your website formats and displays them on the page. But what if Flickr changes their API? Or maybe they are doing server updates when you send the request for your pictures so the Flickr server responds with an error message instead of the requested pictures.
In this instance it would be good for your application to catch the error and tell the user of your site that there was a problem with Flickr and to try reloading the site again in a minute. This is more informative and useful to your users than the program just crashing to a blank page.
Anyway, that's a long way of saying there are some errors you expect and design for, and some you don't expect and cause a catastrophic failure of your application. You think about and handle these types of errors differently.
![Steven Parker](https://uploads.teamtreehouse.com/production/profile-photos/969492/micro_tool_chess_set_2.jpg)
Steven Parker
230,688 PointsThe protocol of a URL is typically "http://".
So it sounds like a "bad" URL is one which is missing this part at the beginning. That would mean the sample you show above would be a "bad" one.
![Brendan Moran](https://uploads.teamtreehouse.com/production/profile-photos/5088532/micro_2013-03-16_18.21.43.jpg)
Brendan Moran
14,052 PointsI think you mean "http://"
!!
:)
![Steven Parker](https://uploads.teamtreehouse.com/production/profile-photos/969492/micro_tool_chess_set_2.jpg)
Steven Parker
230,688 PointsGood catch, I fixed it.