Things can get even more complicated for the Deferred pattern when you pass a Deferred into multiple functions. Even if you use try/catch to make sure you reject the Deferred if a synchronous error occurs, things get murky when the Deferred is used in different functions. Should you reject the Deferred if there’s an error in a logging function?
Because ES6 promises have an associated executor function, they encapsulate all the logic that goes into determining whether the promise succeeded or failed. The users of your code don’t have to guess if or when they’re responsible for resolving or rejecting a deferred.
Remember, as a consumer of an ES6-promise-based API, you are purely reactive
to the promise. You have no way of affecting the promise’s state.