While the option to report all errors (bug 833877) is better than nothing, for testing purposes an ideal solution is only report rejections that end up unhandled. While it's always possible for someone to come along later and add a handler after the fact, it's still useful to know when a promise is initially unhandled.

We're starting to use promises somewhat heavily across some devtools code, and the disappearing errors have caused some lost cycles. Like Benvie points out, using this can lead to some spurious console spew when rejecting a promise before its handlers have been attached. I'm going to weigh in that I'd rather have spurious spew in exceptional situations[1] than let careless coding cause silent exceptions. I guess what I'm saying is: if this were made optional we'd turn it on in the devtools-loaded copy of promises. If this were made default I'd be happy, and if this wasn't included at all I'd be sad. [1] I could be wrong that this is exceptional in the common case, but in our experience I don't think we yet trigger this condition.

Cc'ing the other in-tree promise consumers that I know of.

Whatever we do here needs to wait on bug 810490, but it's probably better to start a discussion about it on the newsgroups

https://github.com/promises-aplus/unhandled-rejections-spec/issues is quite enlightening. As far as I understand, unhandled errors are quite common with |return rejected(err)|.

I'm closing this as wontfix (for now!) as we don't have an agreed upon solution to fix. Please start a discussion in the firefox-dev discussion group and let's get general consensus on what we actually want to implement.