If you look at lib/internals/errors.js, you'll see that ERR_ARG_NOT_ITERABLE is already a TypeError.

ERR_INVALID_TUPLE is already a TypeError

It needs error.constructor equals to TypeError. So inheritance is not allowed.

refs: https://github.com/nodejs/node/blob/master/test/fixtures/wpt/resources/testharness.js#L1662

I would argue that's a bug in the test harness and not our implementation.

const e = new ERR_INVALID_TUPLE('a', 'b');
console.log(e instanceof TypeError); // true

The spec text says only to throw a TypeError, and that is what we're doing here.

our internal errors already satisfy this constraint:

> try { new URLSearchParams([1]) } catch(err) { console.log(err.constructor === TypeError) }
true

2 ways to resolve it:

1. Ignore this case: new URLSearchParams(DOMException.prototype);
2. Fix the code to pass wpt.

Both of the two ways are OK, but current code can't pass that case.

It was fixed in #33857

I'll take a look later.

But new URLSearchParams(DOMException.prototype); is thrown by DOMException.

@targos You're right. The only thing I should fix for error handling is the ERR_INVALID_THIS in lib/internal/per_context/domexception.js.

This is not the correct way of handling this. If you take a look at lib/internals/errors.js, you'll see that some error codes have multiple types in their list... for instance ERR_INVALID_STATE lists Error, TypeError, and RangeError. To create an ERR_INVALID_STATE error this is a TypeError, you simply do new ERR_INVALID_STATE.TypeError("message")

If we decided to add FormData later someone might miss removing this. It would be worthwhile making this replacement dependent on whether FormData is undefined.

Done. I've add typeof FormData === 'undefined'.

/ping @jasnell

/ping @jasnell