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

[Jeremy Orlow]

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.
J

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"
>
> sgtm
>
>
> 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
> 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
> >> >
> >> >
> >
> >
> _______________________________________________
> 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/1fcee926/attachment.html>