CODEWITHSUNDEEP
javascriptasynchronouspromisetry-catch
dylosaur
dylosaur

Reputation: 149

Why would you wrap a Promise in a try/catch block?

I've been reading through Eloquent JavaScript and this chapter on asynchronous programming in particular. I've been mostly understanding it, but one of the examples lost me. Here's that example:

function requestType(name, handler) {
  defineRequestType(name, (nest, content, source,
                           callback) => {
    try {
      Promise.resolve(handler(nest, content, source))
        .then(response => callback(null, response),
              failure => callback(failure));
    } catch (exception) {
      callback(exception);
    }
  });
}

I was trying to figure out why the author wrapped the Promise within a try/request block. To explain it, the author said this:

Note that the call to handler had to be wrapped in a try block to make sure any exception it raises directly is given to the callback. This nicely illustrates the difficulty of properly handling errors with raw callbacks—it is easy to forget to properly route exceptions like that, and if you don’t do it, failures won’t get reported to the right callback. Promises make this mostly automatic and thus less error-prone.

But this was confusing to me, because just shortly before, he said:

Promises make this easier. They can be either resolved (the action finished successfully) or rejected (it failed). Resolve handlers (as registered with then) are called only when the action is successful, and rejections are automatically propagated to the new promise that is returned by then. And when a handler throws an exception, this automatically causes the promise produced by its then call to be rejected. So if any element in a chain of asynchronous actions fails, the outcome of the whole chain is marked as rejected, and no success handlers are called beyond the point where it failed.

So why wouldn't I be able to just write this as:

function requestType(name, handler) {
  defineRequestType(name, (nest, content, source,
                           callback) => {
      Promise.resolve(handler(nest, content, source))
        .then(response => callback(null, response),
              failure => callback(failure));
        .catch(reason => callback(reason));
  });
}

Does it have something to do with the author using .then(response, failure) as opposed to .then(response).catch(failure)? The example above this one is built to handle successes, successful deliveries with failure responses (like incorrect request type used), and totally failed delivery, so maybe it has something to do with that? I've read a couple other similar questions here but I'm still struggling to apply it to these examples, so any help is really appreciated.

Upvotes: 0

Views: 665

Answers (1)

kkmazur
kkmazur

Reputation: 506

Remember that the handler function is a function. That means it is called and processed before the resulting value is passed to the Promise.resolve

the handler function can look like this:

function handler(nest, content, source) { throw new Error(); }

Hence it won't even go to the "Promise world" inside Promise.resolve. And that's why it's required to use try-catch construct. So whatever fails (either promise stage or handler function processing) it'll be handled by the callback.

Upvotes: 2

Related Questions