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

[jasnell]

It's likely that my brain is just fried from a week of bouncing back and forth between two different runtimes ... but it's not immediately clear to me how that helps with making error objects cloneable?

[addaleax]

@jasnell Isn’t the problem that DOMException can’t inherit from JSTransferable because the latter is not multi-context-aware like DOMException itself is?

[jasnell]

Yes and no. We can't require() or use internalBinding() in dom_exception.js currently to pull in JSTransferable. If things were modified to allow JSTransferable and it's symbols to be initialized early and passed in to dom_exception.js, then we could make use of it....
#41038 (comment)

[addaleax]

@jasnell Yeah, that's what I'm saying :)

[jasnell]

I'm not sure that's any less complicated :-) But you're more familiar with that particular area so there may be something I'm not groking yet

[addaleax]

@jasnell If we can avoid implementing an Error subclass in C++ and instead have a generic utility work cross-context, then yeah, I'd say that's worth it. ;)

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.