$q: Unhandled rejections should not be stringified

[dcherman]

Note: for support questions, please use one of these channels: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#question. This repository's issues are reserved for feature requests and bug reports.

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

Unhandled rejections are converted to a string prior to being passed to $exceptionHandler. Also, errors aren't correctly stringified either.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar (template: http://plnkr.co/edit/tpl:yBpEi4).

http://jsfiddle.net/rogqp47y/28/

What is the expected behavior?

The value that the promise was rejected with should be passed to $exceptionHandler

What is the motivation / use case for changing the behavior?

An unhandled rejection should be treated no differently than an unhandled exception - if I throw an uncaught error, I expect to catch that in the global $exceptionHandler, not a string representing the error. The default implementation of $exceptionHandler that logs to the console should handle the stringification.

Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.

Git / Nightly (Future 1.6)

Other information (e.g. stacktraces, related issues, suggestions how to fix)

[gkalpak]

/cc @lgalfaso

[lgalfaso]

I do not think that there is a clear cut (this is that $exceptionHandler should receive the value from an unhandled rejected promise). The reason being that there is no reason to believe that this value will be an Error. This is, if the value is just passed to $exceptionHandler, there is no context to know that this came from an unhandled promise. That said, I am open to change https://github.com/angular/angular.js/blob/master/src/ng/q.js#L383 to exceptionHandler(extends(new UnhandledPromiseError(), {reason: toCheck.value}), errorMessage); (or something equivalent) UnhandledPromiseError being something that extends Error.

[gkalpak]

I agree that it should be clear why this is an error (i.e. possibly unhandled rejection).
I was thinking we might add an independent API about notifying for unhandled rejections. Something similar to the unhandledrejection event.

[dcherman]

So in the current code, I see that we're only passing along one argument to $exceptionHandler, but the second (optional) reason seems like it's be very reasonable to use here in order to report the reason the handler was invoked as "Possibly unhandled rejection" or something. Thoughts?

[lgalfaso]

I find a new service just for this somehow of an overkill. If we are going to change what is sent to $exceptionHandler (that I think it would be a good idea), I would still think it is better to send something that extends Error. How the value is placed in this error (and if we just use Error or something else) all variations are fine with me. About the error message, then having just "Possibly unhandled rejection" or what we currently send are both fine with me.

[vertazzar]

tracebacks look like this:

i know you have to

var defer = $q.defer();

defer.promise.then(function () {
    var xdefer = $q.defer();
    xdefer.resolve(1);
    return xdefer.promise.then(function () {
        console.log(unknownvar); // cause typerr
    });
}).catch(function (e) {
    console.error(e);
});

defer.resolve();

so im asking if there is a way to turn this behaviour off (at least when in development mode) or somehow agument "possible unhandled rejection" with full traceback

[gkalpak]

@vertazzar, you can disable the possibly unhandled rejection errors via $qProvider.errorOnUnhandledRejections(false).