[whatwg] Structured clone for an Error object

Drew Wilson atwilson at google.com
Fri Feb 26 10:44:17 PST 2010

BTW, the spec says that unhandled exceptions are either propagated to the
parent Worker object (in the case of dedicated workers) or reported to the
user via the console (for shared workers).

So I'm not certain why passing Error objects via postMessage() would be
necessary for a spec-compliant UA (note that some UAs have bugs in their
implementation such that not all exceptions in Workers are logged to the
console, but that shouldn't motivate a change in the spec).


On Thu, Feb 25, 2010 at 8:21 PM, ATSUSHI TAKAYAMA <
taka.atsushi at googlemail.com> wrote:

> Hi,
> Right now, in the spec "2.7.5 Safe passing of structured data", it says
> If input is another native object type (e.g. Error)
> Return the null value.
> but if we want to debug workers, it's more convenient to be able to
> pass the error directly rather than
> postMessage({name: err.name, message: err.message})
> which loses all information like line number, etc. or we will just
> start cloning every property of the Error (stack, lineNumber,
> stacktrace, etc depending on the browser).
> I think that's an unnecessary chore for all developers. We should just
> be able to postMessage an error.
> (of course, the best solution would be to be able to console.debug
> from a worker thread, but it's not a standard way yet)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100226/255addfd/attachment-0002.htm>

More information about the whatwg mailing list