Add assert.throws

[domenic]

No description provided.

[bterlson]

Your example isn't validating that a TypeError is thrown, is it? Seems to only pass one parameter...

[domenic]

Ah damn I forgot to amend that commit before pushing up. Will do when I get back to my computer.

[domenic]

Fixed.

Maybe we should add an arity check (perhaps testing that neither param is undefined? or that both are functions?) to prevent this in the future?

It's a potential mistake for people coming from other frameworks where assert.throws(() => {}) works and asserts that anything at all is thrown. For test262 we don't an imprecise version like that of course, but people might do it accidentally like I did.

[bterlson]

Yeah I think a check is good. Possibly just a check for func being defined is sufficient?

[domenic]

Added

[bterlson]

Do you think it's best to return after the $ERROR call so it bails out? Might prevent showing spurrious errors.

[domenic]

Oh, I thought $ERROR was equivalent to throw Test262Error...

[bterlson]

No, that was the intention for $FAIL. $ERROR is "implementation defined" but may not throw to support reporting multiple errors from the same file.

[bterlson]

$ERROR(err) is effectively $DONE(err) I think. We probably don't need both even :-P.

[smikes]

We need both because $DONE also indicates async

On Wed, Dec 3, 2014 at 6:57 PM, Brian Terlson [email protected]
wrote:

$ERROR(err) is effectively $DONE(err) I think. We probably don't need both even :-P.

Reply to this email directly or view it on GitHub:
#131 (comment)

[domenic]

Fixed to add return statements.

In light of this I'm less confident about removing $FAIL.

[bterlson]

LGTM. Still not sure why FAIL is needed but perhaps we can discuss this once I specify the test262 environment more rigorously.