(In reply to Hamish Willee from comment #4) > What were you thinking of for a release note? Or to put it more specifically, why is it useful to be able to serialize a DOMException? I mean I think this allows you to call StructuredClone() on an exception, but not sure when and why you would want to - is there a specific/real use case?? Per https://github.com/whatwg/html/issues/4268 this was introduced mainly for stream objects transferred from different realms can pass the JS errors to the current realm. (This bug is only about DOMException as JS errors are not covered yet) This also means anything that works in parallel can now pass the DOMException as-is, rather than manually crafting JSON data to signal there was an error. > Does that sound reasonable? Yup, looks good. > - Does this serialization affect/get made use of by anything other than [`structuredClone()`](https://developer.mozilla.org/en-US/docs/Web/API/structuredClone)? I mean, for example, might this now allow you to call toJson on a DOMException to get the serialized format when you couldn't before? `postMessage()` also uses serializable, so devs can now pass errors across workers. There's no `toJSON` though, that's a different thing and it's not in the spec. > - Do you know when Chrome started supporting this as serializable? https://bugs.chromium.org/p/chromium/issues/detail?id=970079, but I don't have the exact version number.
Bug 1561357 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Hamish Willee from comment #4) > What were you thinking of for a release note? Or to put it more specifically, why is it useful to be able to serialize a DOMException? I mean I think this allows you to call StructuredClone() on an exception, but not sure when and why you would want to - is there a specific/real use case?? Per https://github.com/whatwg/html/issues/4268 this was introduced mainly for stream objects transferred from different realms to be able to pass the JS errors to the current realm. (This bug is only about DOMException as JS errors are not covered yet) This also means anything that works in parallel can now pass the DOMException as-is, rather than manually crafting JSON data to signal there was an error. > Does that sound reasonable? Yup, looks good. > - Does this serialization affect/get made use of by anything other than [`structuredClone()`](https://developer.mozilla.org/en-US/docs/Web/API/structuredClone)? I mean, for example, might this now allow you to call toJson on a DOMException to get the serialized format when you couldn't before? `postMessage()` also uses serializable, so devs can now pass errors across workers. There's no `toJSON` though, that's a different thing and it's not in the spec. > - Do you know when Chrome started supporting this as serializable? https://bugs.chromium.org/p/chromium/issues/detail?id=970079, but I don't have the exact version number.
(In reply to Hamish Willee from comment #4) > What were you thinking of for a release note? Or to put it more specifically, why is it useful to be able to serialize a DOMException? I mean I think this allows you to call StructuredClone() on an exception, but not sure when and why you would want to - is there a specific/real use case?? Per https://github.com/whatwg/html/issues/4268 this was introduced mainly to let stream objects transferred from different realms pass the JS errors to the current realm. (This bug is only about DOMException as JS errors are not covered yet) This also means anything that works in parallel can now pass the DOMException as-is, rather than manually crafting JSON data to signal there was an error. > Does that sound reasonable? Yup, looks good. > - Does this serialization affect/get made use of by anything other than [`structuredClone()`](https://developer.mozilla.org/en-US/docs/Web/API/structuredClone)? I mean, for example, might this now allow you to call toJson on a DOMException to get the serialized format when you couldn't before? `postMessage()` also uses serializable, so devs can now pass errors across workers. There's no `toJSON` though, that's a different thing and it's not in the spec. > - Do you know when Chrome started supporting this as serializable? https://bugs.chromium.org/p/chromium/issues/detail?id=970079, but I don't have the exact version number.