Allow throws / throwsAsync to work with any value, not just errors

[novemberborn]

t.throws() and t.throwsAsync() require the resulting exception to be a proper error:

ava/lib/assert.js

Lines 147 to 154 in 952a017

	if (!isError(actual)) {
	throw new AssertionError({
	assertion,
	message,
	savedError,
	values: [formatWithLabel(`${prefix} exception that is not an error:`, actual)]
	});
	}

I propose we add an any: boolean option to the expectations object used for these assertions. If true it won't cause a failed assertion when the exception is not an error.

We need to update the validation logic here to allow this property:

ava/lib/assert.js

Line 74 in 952a017

function validateExpectations(assertion, expectations, numberArgs) { // eslint-disable-line complexity

Don't forget to update the type definition:

ava/index.d.ts

Line 11 in 952a017

export type ThrowsExpectation = {

If any is true, we should try and change the typing of the return value to be unknown:

ava/index.d.ts

Line 252 in 952a017

<ThrownError extends Error>(fn: () => any, expectations?: ThrowsExpectation | null, message?: string): ThrownError;

ava/index.d.ts

Line 263 in 952a017

<ThrownError extends Error>(fn: () => PromiseLike<any>, expectations?: null, message?: string): Promise<ThrownError>;

And update our own tests:

ava/test-tap/assert.js

Line 786 in 952a017

test('.throws()', gather(t => {

ava/test-tap/assert.js

Line 976 in 952a017

test('.throwsAsync()', gather(t => {

See also the discussion in #1841.

[sindresorhus]

I think we should add a short note to the docs that if the user is in control of the error, they should prefer to make it a proper Error.

[randomicon00]

Hello @novemberborn & @sindresorhus, I would like to tackle this issue if possible.

Thank you,

[novemberborn]

@randomicon00 that's great go for it 😄

[randomicon00]

@novemberborn Will do thanks :)

[dmaevsky]

@sindresorhus @novemberborn
There are very valid use cases where throwing a non-error value not only makes sense but is almost the only viable solution.
My particular case is a sort of asynchronous calculation graph implementation, where any node can either have a value, or be in an 'error' or 'stale' state, so when a node is trying to calculate its value and one of its dependencies is either an error or is stale, I would prefer to propagate this state by re-throwing it.
However using a 'magic' string for the stale state instead of an Error class allows for very subtle logic since I can write something like if (error === STALE) { ... } which would be impossible with an instance of a class.
Comparing values using === is exactly how most reactivity systems implement their logic.

Currently in each and every test I have to wrap my functions that can throw STALE in order to test them. This is quite ridiculous.
IMO, if one specifies { is } in the Expectation that should be perfectly OK to allow values of any type. Even better design would be to pass a function (err) => expectation(err) instead of Expectation. Then I would be able to use any asserts already in t, e.g. t.throws(() => myCode(), err => t.is(err, STALE)) or t.throws(() => myCode(), err => t.true(err instanceof Whatever))

In any case I find it quite weird that a testing framework should be opinionated about which values the code being tested might throw :)

[adiSuper94]

@novemberborn I'd like to take a crack at this.

[randomicon00]

It assigned to me, I still didn't complete it but you can try I guess. I am still working on it.

[adiSuper94]

@randomicon00 , it's cool if you are working on it. I though that it was inactive, so asked.

[travis]

any updates on this? it's very annoying that there is no escape hatch...