[webkit-dev] Reporting exceptions from worker context to users

Drew Wilson atwilson at google.com
Sat Aug 1 12:39:58 PDT 2009


Yes, SharedWorkers will eventually be able to communicate with one another,
as will DedicatedWorkers. So at some point we'll have a big connected graph
of workers that potentially might be interesting for people to traverse and
inspect their global contexts (I'm not sure - I don't think we know yet what
debugging tools will be useful for developers).
Further agreed, the HTML5 spec states that exceptions from shared workers
are *not* propagated to parent pages for application execution - this would
be solely for logging purposes.

In the meantime while we work towards our glorious future, I'd still like to
log exceptions somewhere :) It sounds like we have one vote for "just log
them to the console for every connected document".

-atw

On Sat, Aug 1, 2009 at 10:35 AM, Michael Nordman <michaeln at google.com>wrote:

> Shared workers can also communicate directly with one another, is that
> right? And its possible to have a shared worker whose only client is
> another shared worker, is that right?
>
> Feels like we should be working towards inspecting shared workers
> directly. Where a page inspector would show which shared workers it
> was connected to, and you could open a separate inspector to see what
> is going on within each shared worker (including which shared workers
> it was connected to).
>
> Broadcasting exceptions within a worker to its clients for inspection
> purposes may be useful even with separate inspectors per shared
> worker. The client's 'shared worker' tab  (or console) could log
> unhandled exceptions occurring in each, as you described, encouraging
> the developer to look into it... open the shared worker inspector and
> poke around.
>
> About broadcasting unhandled shared worker exceptions in general...
>
> It makes sense to have unhandled exceptions in a dedicated process
> propagated to the parent page's context (which may presumably handle
> the exception in some way). But I'm not sure that model applies to
> unhandled exceptions in shared workers. The possibility of multiple
> connected pages, which should "handle it"? Seems good for
> logging/debugging purposes to have them show up in the client's
> inspector, but doesn't sound like a good fit for application execution
> purposes.
>
>
> On Sat, Aug 1, 2009 at 9:31 AM, Drew Wilson<atwilson at google.com> wrote:
> > Hi all,
> > Currently, unhandled exceptions are sent from worker context over to the
> > parent page where they are logged to the console. This works fine for
> > dedicated workers, but not for shared workers which can have multiple
> active
> > windows.
> > The immediate solution that springs to mind is to broadcast the exception
> to
> > every window associated with a shared worker, and have each window log
> the
> > unhandled exception to its console. Is there another option that might be
> > better (is there the concept of an inspector/console that is not
> associated
> > with a specific window, for example)?
> > -atw
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090801/e37a76f8/attachment.html>


More information about the webkit-dev mailing list