Fixed with AngularJS version 1.6
The reasoning for this behavior was that an uncaught error is different than a regular rejection, as it can be caused by a programming error, for example. In practice, this turned out to be confusing or undesirable for users, since neither native promises nor any other popular promise library distinguishes thrown errors from regular rejections. (Note: While this behavior does not go against the Promises/A+ spec, it is not prescribed either.)
$q:
Due to e13eea, an error thrown from a promise's
onFulfilled
oronRejection
handlers is treated exactly the same as a regular rejection. Previously, it would also be passed to the$exceptionHandler()
(in addition to rejecting the promise with the error as reason).The new behavior applies to all services/controllers/filters etc that rely on
$q
(including built-in services, such as$http
and$route
). For example,$http's transformRequest/Response
functions or a route's redirectTo function as well as functions specified in a route's resolve object, will no longer result in a call to$exceptionHandler()
if they throw an error. Other than that, everything will continue to behave in the same way; i.e. the promises will be rejected, route transition will be cancelled,$routeChangeError
events will be broadcasted etc.-- AngularJS Developer Guide - Migrating from V1.5 to V1.6 - $q