fix(core): error registration could pollute constructors

[AaronO]

Our previous approach would pollute constructors (e.g: DOMExceptionOperationError) and thus break certain type checks.

Notes

One downside to this approach is that it adds an extra line to stacktraces:

❯ deno eval "Deno.openSync(null)"
error: Uncaught TypeError: Error parsing args: serde_v8 error: ExpectedString
Deno.openSync(null)
     ^
    at unwrapOpResult (deno:core/core.js:99:13)
    at Object.opSync (deno:core/core.js:113:12)
    at Object.openSync (deno:runtime/js/40_files.js:32:22)
    at file:https:///Users/aaron/git/deno/$deno$eval.ts:1:6

~/git/deno core/fix-complex-error-registration*
❯ ./target/debug/deno eval "Deno.openSync(null)"
error: Uncaught TypeError: Error parsing args: serde_v8 error: ExpectedString
Deno.openSync(null)
     ^
    at deno:core/core.js:86:60
    at unwrapOpResult (deno:core/core.js:106:13)
    at Object.opSync (deno:core/core.js:120:12)
    at Object.openSync (deno:runtime/js/40_files.js:32:22)
    at file:https:///Users/aaron/git/deno/$deno$eval.ts:1:6

So maybe the args list is the lesser evil

[ry]

I'm a bit confused about the purpose of this.

Our previous approach would pollute constructors (e.g: DOMExceptionOperationError) and thus break certain type checks.

Break what type checks? Is this fixing a bug - is there a test that could be added?

[lucacasonato]

Thanks. I have added a regression test. This unblocks #7819.