[webkit-reviews] review requested: [Bug 21918] A JavaScript Exception abstraction : [Attachment 25364] ScriptState (concept only)

[bugzilla-daemon at webkit.org]

Dimitri Glazkov (Google) <dglazkov at chromium.org> has asked  for review:
Bug 21918: A JavaScript Exception abstraction
https://bugs.webkit.org/show_bug.cgi?id=21918

Attachment 25364: ScriptState (concept only)
https://bugs.webkit.org/attachment.cgi?id=25364&action=review

------- Additional Comments from Dimitri Glazkov (Google)
<dglazkov at chromium.org>
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.