[breaking] Don't convert non-Error promise rejection reason

[kasperlewau]

Promises that are rejected with a non-Error are currently passing expectations as we're converting to an Error in lib/assert.

This PR changes the behaviour of t.throws so that it no longer considers the following example a pass:

test(async t => {
 await t.throws(Promise.reject('foo'), 'foo');
});

If the rejection reason is a non-Error, core-assert catches this which results in an AssertionError.

Whereas the following would pass with flying colors:

test(async t => {
  await t.throws(Promise.reject(new Error('foo'), 'foo');
});

---

Docs for t.throws saw a minor addition;

Assert that function throws an error**,** or promise rejects with an error.

Fixes #468

[mention-bot]

By analyzing the blame information on this pull request, we identified @therealklanni, @sotojuan and @SamVerschueren to be potential reviewers

[vadimdemedes]

I remember we had some back and forth with this decision, but atm I'd also like to merge this and strictly expect Error objects.

[kasperlewau]

I suppose yielding a custom Error to the consumer with a recommendation to reject Promises with actual Errors would be somewhat of a middle ground, if we're in 'back and forth land' that is?

A missing expectation AssertionError doesn't explicitly highlight that fact (imho), but I didn't take a good look at what the error stack yielded as it stands. A custom Error could just be extraneous information.

[novemberborn]

I remember we had some back and forth with this decision, but atm I'd also like to merge this and strictly expect Error objects.

We all seem to be in agreement in #468 so let's not restart this argument 😉

[novemberborn]

Remove the if-guard as well, simply throw fnError. This makes it equivalent to t.throws(() => { throw 'foo' }).

[kasperlewau]

Very well! I'll go ahead and amend my commit if you don't mind, and save myself the trouble of having to squash later.

[novemberborn]

Sure. It's going to conflict with #576 though 😉

[kasperlewau]

Right. I'll get on this once #576 is merged.

[novemberborn]

@sindresorhus this will be a breaking change.

[sindresorhus]

this will be a breaking change.

True, although I really doubt (hope) nobody depends on this behavior.

[sindresorhus]

Thanks @kasperlewau :)

[kasperlewau]

Thank you(s)!