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

JavaScript

So, you need to be very familiar with what kind of error would take place for each event for try/catch?

The error handlings are difficult because I don't really know what kind of errors may be going to happen unless you are very familiar with the error handling practice.

The error handlings on response.on('error') and request.on('error') are understandable. Node seems to recommend to implement the handlings. I guess try/catch for JSON.parse is understandable too because it is easy to see that it is necessary for the string to have a JSON format to have the function make sense. But try/catch right before https.get() seems like a redundant. I don't know why request.on('error') cannot catch the possible error. Andrew says this is from the developer's perspective, so I guess this try/catch is not very normal? It's like doing:

 try {
   console.log("hello world");
 } catch {}

You end up using try/catch for every single function to make sure the possible errors are handled???

2 Answers

Steven Parker
Steven Parker
231,007 Points

Things like a function called with a literal argument are completely predictable and would never require exception handling.

But an error event is not quite the same thing as an exception. An error event might be generated during the asynchronous processing, but a problem with the initial setup could cause an exception instead. So it makes sense that in some situations you might do both.

Ari Misha
Ari Misha
19,323 Points

Hiya there! How would you know what kind of error an asynchronous call might throw? I like to handle errors with Promises 'coz pretty much all asynchronous calls return Promises, and Promises works with resolve and reject handlers. Take a look at this code:

function postLetter(letter, address) {
  var deferred = new $.Deferred();
  if (canSendTo(address)) {
    letter.sendTo(address, function () {
      deferred.resolve(letter.getTrackingCode());
    });
  else
    deferred.reject("Cannot reach address " + address);
  return deferred.promise();
}

Notice the mixin of jQuery in there. So an async function creates a deferred object that provides the necessary functionality. Then, the function will return the promise that is created by the deferred object. The function resolves the deferred in case of success or rejects it in case of failure. Thats why Promise API is so helpful when it comes to the asynchronous hell.

~ Ari