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).<div><br></div><div>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).</div>
<div><br></div><div>-atw<br><br><div class="gmail_quote">On Thu, Feb 25, 2010 at 8:21 PM, ATSUSHI TAKAYAMA <span dir="ltr"><<a href="mailto:taka.atsushi@googlemail.com">taka.atsushi@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
Right now, in the spec "2.7.5 Safe passing of structured data", it says<br>
<br>
If input is another native object type (e.g. Error)<br>
Return the null value.<br>
<br>
but if we want to debug workers, it's more convenient to be able to<br>
pass the error directly rather than<br>
<br>
postMessage({name: <a href="http://err.name" target="_blank">err.name</a>, message: err.message})<br>
<br>
which loses all information like line number, etc. or we will just<br>
start cloning every property of the Error (stack, lineNumber,<br>
stacktrace, etc depending on the browser).<br>
<br>
I think that's an unnecessary chore for all developers. We should just<br>
be able to postMessage an error.<br>
<br>
(of course, the best solution would be to be able to console.debug<br>
from a worker thread, but it's not a standard way yet)<br>
<br>
A. TAKAYAMA<br>
</blockquote></div><br></div>