[webkit-dev] Reporting exceptions from worker context to users
jorlow at chromium.org
Sat Aug 1 13:06:03 PDT 2009
I think logging to all connected pages' console is fine for now, but I think
Michael's suggestion (or something similar) should be implemented in the not
too distant future. Definitely before shared workers are allowed to
communicate with each other.
On Sat, Aug 1, 2009 at 12:45 PM, Michael Nordman <michaeln at google.com>wrote:
> > it sounds like we have one vote for "just log them to the console for
> every connected document"
> On Sat, Aug 1, 2009 at 12:39 PM, Drew Wilson<atwilson at google.com> wrote:
> > Yes, SharedWorkers will eventually be able to communicate with one
> > as will DedicatedWorkers. So at some point we'll have a big connected
> > of workers that potentially might be interesting for people to traverse
> > inspect their global contexts (I'm not sure - I don't think we know yet
> > 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
> > be solely for logging purposes.
> > In the meantime while we work towards our glorious future, I'd still like
> > 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
> >> > 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
> >> >
> >> >
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev