Ensure unhandled rejections cause test failure.

[rwjblue]

Prior to this change, an unhandled exception in a promise that was not returned from the test callback would not cause test failure.

For example, the following (using default out of the box settings) results in test failures:

test('native promises cause an unhandled rejection', function(assert) {
  // imagine this was "deep" inside various method calls
  setTimeout(function() {
    throw new Error('whoops!');
  });

  // other things that we are trying to test
  assert.deepEqual(someMethod(), ['one', 'two']);
});

And this (prior to this PR) would result in a passing test suite:

test('native promises cause an unhandled rejection', function(assert) {
  // imagine this was "deep" inside various method calls
  Promise.resolve().then(function() {
    throw new Error('whoops!');
  });

  // other things that we are trying to test
  assert.deepEqual(someMethod(), ['one', 'two']);
});

The reason that what we are doing already isn't good enough is:

• HTML Reporter: the default unhandledRejection handler does not dispatch to window.onerror at all... 😩
• Node CLI: unhandled rejections in Node 6.6 and higher emit a console warning, but nothing else

[Krinkle]

'onrejectionhandled' in window might be easier to maintain as a feature test, or are there false positives for that? That way when other browsers land support, our CI will verify them automatically.

[rwjblue]

Awesome, thank you for that. Hard coding to Chrome definitely felt bad, but it was late and I ran out of ideas. 😝

[rwjblue]

Also just confirmed that Safari also supports the unhandled rejection events, thanks again for the pointer on the feature detect!

[rwjblue]

I took some time to experiment with the implementation (by polyfilling in emberjs/ember-qunit#306), and it seems that just using QUnit.onError was quite the right implementation. QUnit.onError is closely tied to window.onerror semantics (returning true or false for bubbling, the specific argument signature for stack trace, etc). Instead of making it much more complicated I created a QUnit.onRejectionHandler method to specifically handle this case.

I also updated the tests to ensure that we are testing both inside and outside of a single test context, and modified to use a more appropriate feature detection (instead of only testing on Chrome). The new tests pass properly on both Chrome and Safari (which are the only two browsers which have implemented onunhandledrejection to my knowledge).

[rwjblue]

Note: I'm happy to squash the commits down when we are ready to go on this one. It is easier to push new commits (e.g. maintainers have an easier time of reviewing the subset of the diff that is new).

[platinumazure]

Just left a small comment. I promise to give this a full review later 😄

[platinumazure]

Curious to know why this comment is de-indented from the line below.

[rwjblue]

Just a mistake, though I'm surprised that the otherwise aggressive indentation linting rules didn't catch it...

[platinumazure]

No worries. The indent rule is slightly lenient about comments because in general it is hard to tell what lines of code a comment might be associated with, so ESLint generally allows comments to align with the next line of code, the previous line of code, or with the "correct" indentation (i.e., the indentation we would expect a token to actually be at if this were a token instead of a comment).

My guess is the indent rule is allowing this location due to aligning with line 9. That seems weird since line 10 is whitespace-only, so I wonder if we could improve the rule to not use the previous-line heuristic if the previous token is actually 2 lines above the comment instead of 1 (and similarly, not use the next-line heuristic if the next token is actually 2 lines below the comment instead of 1).

[rwjblue]

Totally makes sense! (also cleaned up the indentation)

[platinumazure]

For what it's worth, I've opened eslint/eslint#9733 about the comment indent issue.

[trentmwillis]

Overall, looks good to me. Just two minor comments.

[trentmwillis]

Is reason just an Error instance?

[rwjblue]

No, reason is whatever the rejection value is. An Error instance is almost certainly the most common thing that reason would be, but it could also be a failed XHR, a string, undefined, null, etc. The value here is either whatever the argument to reject() or the argument tothrow is.

See small demo JSBin with the following content:

window.addEventListener('unhandledrejection', function(event) {
  console.log('reason:', event.reason);
})

Promise.reject();
Promise.reject(null);
Promise.reject("asdf");
Promise.resolve().then(() => {
  throw new Error('boom');
})

[trentmwillis]

Ah okay, makes sense. Early-morning me couldn't quite make that connection.

[trentmwillis]

Correct me if I'm wrong, but can't this just be Promise.resolve().then( ... )? If so, can you change it here and below as well.

[rwjblue]

Yep, you are absolutely correct. I have been working too much with Ember's internal Ember.RSVP.Promise which is configured to resolve in an "odd" way, sorry about that!

Updated to be much more idiomatic...

[platinumazure]

LGTM, thanks!

[trentmwillis]

Looks good to me. @Krinkle any other feedback before I merge?

[trentmwillis]

Thanks @rwjblue!