[Webkit-unassigned] [Bug 21918] A JavaScript Exception abstraction

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=21918


dglazkov at chromium.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #24849|0                           |1
        is obsolete|                            |
  Attachment #25364|                            |review?
               Flag|                            |




------- Comment #11 from dglazkov at chromium.org  2008-11-21 14:59 PDT -------
Created an attachment (id=25364)
 --> (https://bugs.webkit.org/attachment.cgi?id=25364&action=view)
ScriptState (concept only)

I would like to get this right, so please bear with me.

It looks like for the purposes of carrying the exception information, we
actually need only the non-CallFramey members of JSC::ExecState: the
hadException(), exception() and friends. So, perhaps the right solution would
be to introduce a ScriptState abstraction, which only exposes these methods?

See the attachment. There, I just typedef'd ScriptState, but potentially, it
seems logical to have it as a separate class with a callFrame() method, which
then gives you the actual CallFrame info, i.e.:

  Script State --(has a)--> Script CallFrame 

Does this make better sense? I plead for guidance and thought-sharing. I don't
mind the hazing :)

Is the general direction that JSC::ExecState would eventually become
JSC::CallFrame and at some point shed the globalData accessors?

In the context of Chromium, it would perfect to have a non JSC-specific class,
which can be passed through WebCore to NodeFilter, NodeIterator, et al. and
store exception information.

I don't know much about non-JS bindings, but would be happy to hear any ideas
as well. It seems we need cover scenarios with Non-JS node filter, as well as
JS-originated node filter, but non-JS iteration calls.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.