| 02:00 | <Mathieu Hofman> | are wasm opaque objects exposed directly to JS code? My impression was that there is currently glue code to wrap those. Now of course we could ask the question for when wasm objects are no longer opaque and gain prototypes, and possibly own props. My concern is that I don't want to introduce yet another "kind" of Error that all error aware code out there needs to recognize (not just debuggers). We have Error instances, and I guess we're also getting objects extended with Error.captureStackTrace. |
| 02:03 | <Mathieu Hofman> | especially now that we have Error.isError, I think it'd be a mistake to introduce something that isn't an error but behaves like one. It's already unfortunate enough we have to standardize captureStackTrace |
| 02:19 | <guybedford> | Mathieu Hofman: the wasm custom descriptors proposal turns the opaque objects directly into objects with descriptors allowing getters and setters etc. |
| 02:19 | <guybedford> | they thus effectively become resource types, backed by a wasm gc managed struct or array |
| 02:23 | <guybedford> | I'd have thought the solution though would be to call out to wrapErr(scalaErr) => Object.assign(new Error(), { gcError: scalaErr }) through to JS when there is an error to have a JS error type wrapping a scala error type instead of the converse, but I haven't thought about it deeply enough to have a strong opinion |
| 02:32 | <Mathieu Hofman> | Right, even with custom descriptors support, this is effectively purpose built glue code creating JS objects to expose wasm things. In that case, I would find it natural to create a new Error() and define on it a cause: wasmThrowable property. |