Fix inconsistency in rejects.toThrow()

[lstkz]

fixes #6675

With this fix sync and async versions of toThrow are consistent.

However, throwing non-errors is not a good practice because we don't have the stack trace.

[SimenB]

Seems like a reasonable change to me 🙂 While I agree everything thrown should be a subclass of Error, we shouldn't make assumptions.

Mind taking a look at the failing tests?

This should also get a changelog entry 🙂

[lstkz]

I am checking failed tests and this is confusing.
Example failing test:

// jest/packages/expect/src/__tests__/to_throw_matchers.test.js

test('passes', async () => {
   await jestExpect(asyncFn(false, true)).resolves.not[toThrow]();
});

asyncFn(false, true) resolves to Promise.resolve('apple')

My fix

 if (fromPromise && /*isError(actual)*/) {
                  // ^^^^^^ removed this
    error = actual;
  }

It doesn't make sense to use resolve and toThrow and the same time because if there is an error then the promise is always rejected.
In other words, assertion expect(promise).resolve.not.toThrow() should never fail for any code.

My suggestion would be to support toThrow only in rejects and remove it from resolve.

[SimenB]

My suggestion would be to support toThrow only in rejects and remove it from resolve.

I think that makes sense! Or throw a useful "toThrow should only be used with rejects, not resolves".

[SimenB]

@thymikee @rickhanlonii thoughts?

[Yaojian]

@BetterCallSKY I use custom objects instead of subclasses of Error becuase there is a limitation in TypeScript when compiling to ES5

[thymikee]

Seems like a reasonable change to me 🙂 While I agree everything thrown should be a subclass of Error, we shouldn't make assumptions.

👍 If we can be consistent, let's do it.

[lstkz]

Does it make sense to split it to rejects and resolves? It would be enough to have only promise property.

Examples

// new
expect(value).promise.toEqual(expected); 
// old
expect(value).resolves.toEqual(expected);

// new
expect(value).promise.toThrow(error); 
// old
expect(value).rejects.toThrow(expected);

https://jestjs.io/docs/en/expect
Currently, all thoThrowXYZ methods can be used only with rejects, all other assertions should be used with resolves. Hence, it can be combined because there no conflicts.

I can submit a PR, but it will be a breaking change in the API.

[thymikee]

@SimenB wdyt? My take is we shouldn't drop rejects/resolves because they were designed to read nicely. I'm fine with adding .promise or something next to it

[github-actions]

This PR is stale because it has been open 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

[github-actions]

This PR was closed because it has been stalled for 30 days with no activity. Please open a new PR if the issue is still relevant, linking to this one.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.