Making `DOMException` and `AbortError` cloneable

[jasnell]

Currently, custom error objects implemented in JavaScript are not cloneable via postMessage / structuredClone with perfect fidelity.

e.g.

const d = new DOMException('foo', 'AbortErr');
const mc = new MessageChannel();
mc.port1.onmessage = ({data}) => {
  console.log(data is DOMException); // false
  console.log(data.name); // AbortErr
  console.log(data.message); // 'foo'
  console.log(data.code); // undefined
};
mc.port1.postMessage(d);

Likewise, AbortError is also not correctly cloneable.

The current way that DOMException is implemented (in JavaScript during the per_context bootstrap), it is not possible for us to use the existing internal/worker/js_transferable mechanisms to make it cloneable as the DOMException is loaded too early.

However, if we reimplement DOMException as a native host object (within a C++ binding extending BaseObject) then we can easily make it cloneable (likewise with AbortError). Before going through that effort, however, I wanted to see what folks thought.

/cc @addaleax @joyeecheung

[addaleax]

Is it not possible to also load internal/worker/js_transferable early, before DOMException? It doesn’t really depend on anything else, I think.

[joyeecheung]

Is it not possible to also load internal/worker/js_transferable early, before DOMException?

That's probably not going to work, if it needs to have internalBinding to get the symbols and the bindings, because per-context scripts are run before internalBinding is created. I believe DOMException are in per-context scripts because they are needed in VM contexts, but for now it doesn't make sense to create a copy of internalBinding for every context, so rewriting it in C++ is probably still the way to go.

[joyeecheung]

On a second thought, it might still be possible to keep this in JS if instead of using internalBinding to access stuff created in C++, you pass what it needs from the C++ layer directly into the scripts. Although for that to work you'd need to update InitializePrimordials in src/api/environment.cc and create a mechanism to pass different arguments into different per-context scripts (right now they all get [global, exports, primordials] as the arguments passed into the function wrapper), which would probably be like a poor-man's internalBinding.

[jasnell]

Looking through that code, just implementing DOMException as a BaseObject still seems like the easiest path unless there's some bit of code initialized before internalBinding() that needs the ability to create a DOMException?

[jasnell]

@addaleax :

Is it not possible to also load internal/worker/js_transferable early, before DOMException? It doesn’t really depend on anything else, I think.

Sadly no. We also can't load it lazily using require() as the require() that is in scope for per_context scripts is not internal aware.

[addaleax]

@jasnell I think it would still be worth doing this the “right” way and making JSTransferable and its (very few) dependencies multi-context-aware, that feels like the most future-proof thing anyway