Derek Schuff

Relatedly, are non-atomic stores guaranteed to be observed by "later" non-atomic loads on another thread? (or by atomic loads?)

> IIUC, if there are no atomics forming that happens-before relationship across threads A and B, then a non-atomic store on thread A might in principle never be observed on...

Yes, this basically wraps/unwraps as you said. Because of that I don't think we need special handling for catch, because it would be the same as catching an exception with...

I've rebased this against #301 to make it easier to review. One aspect becomes trivial because #301 already handles allocating the JS tag. So this just becomes about the right...

> If the attribute works (and I don't see why it wouldn't), we should prefer it over further manual adjustments to the "create a namespace object" algorithm. You'll need to...

> Unfortunately I don't have time to follow all the changes in detail, but some comments below. This change is now pretty trivial; But the exnref change is fairly large,...

> The reason for the custom algorithm is that the exception classes are modeled after the ones that exist in JavaScript itself, and those couldn't be specified in WebIDL. The...

@thibaudmichaud @sjrd, continuing the discussion from https://github.com/WebAssembly/exception-handling/pull/301#discussion_r1559281361 > Continuing the discussion from [#301 (comment)](https://github.com/WebAssembly/exception-handling/pull/301#discussion_r1560111669) > > > if you created a WebAssembly.Exception(WebAssembly.JSTag, payload) and threw it into wasm, it would...

I could imagine that being actually useful though? If you have a JS object stored in an externref in wasm, I can imagine that you might want to throw it,...

Any more comments on this? The current version just uses the WebIDL attribute with a getter, and also contains the restriction that creating a `WebAssembly.Exception` object using the JS tag...