[webkit-dev] Reporting exceptions from worker context to users
Michael Nordman
michaeln at google.com
Sat Aug 1 12:45:22 PDT 2009
> 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
>> >
>> >
>
>
More information about the webkit-dev
mailing list