jQuery 3.0 Released
I&#x27;ve complained a few times about what seems to me, to be a less-friendly way of handling Promise rejections in es6.<p>Consider the relatively common use-case - there is a service object which proxies requests, format&#x27;s the call to the backend (or fetches from cache) and format&#x27;s the returned response for the caller of the object. So the pattern looks something like: ServiceObject.fetchData(query).then((data) =&gt; { &#x2F; * display data * &#x2F; }, 
(err)=&gt; { &#x2F; * catch error - display no results * &#x2F;})<p>At some-point you want to chain the promise to update another part of the ui: promise.then((data) =&gt; {
&#x2F;* display something else <i>&#x2F; }, (err) =&gt; { &#x2F;</i> catch error - display failed to load *&#x2F; }).<p>The problem is you can&#x27;t squash the error in the &#x27;reject&#x27; of the previous promise now, because otherwise the error isn&#x27;t propagated to the last promise in the link and instead you will hit the &#x27;success&#x27; function.  This &#x27;reject&#x27; behavior is alright if there is something your &#x27;success&#x27; function can do when the original request failed, but in a great majority of cases if the request failed there is nothing you can do - you put a &#x27;reject&#x27; in the first chain of the promise resolution (potentially in the serviceObject itself) with some generic flash-message like &#x27;request failed please try again&#x27; and call it good. As it stands you end up with a call chain where what a function higher up in the chain should return should be based on what a resolving function further down the chain is doing -- not having to do this was for me was almost entirely the plus-side of the promise-style over callbacks-style concurrency model.<p>I bring this up now because curiously the jQuery model of Deferred() precisely did not do this before -(see section#2 of Major Changes):<p>&gt; Example: returns from rejection callbacks<p>if an error wasn&#x27;t re-thrown in a catch, the promise-handling would stay in the &#x27;reject&#x27; chain as long as an error had been thrown. I am quite curious as to why the current-model won, I understand some of the potential benefits but in practice I find that this behavior is worse in 90% of use-cases that I have encountered. If someone has a link to a mailing-thread &#x2F; issue where this was discussed I would be quite interested.