Oliver Hunt wrote:
On Aug 11, 2009, at 11:13 AM, Brian Barnes wrote:
Darin Adler wrote:
The design is that the return value is ignored. In theory, you can
safely return anything, even a garbage pointer.
-- Darin
Just so I get the concept (how exceptions are handled is one of the
places that is completely different in Spidermonkey so it's one of
the biggest hurdles for me) -- when the class based SET property or a
STATIC FUNCTION is called, it detects when an exception is thrown by
my replacement of the JSValueRef *exception, correct? There's
nothing else I have to trigger (in SM you have to implicitly trigger
by calling a function.)
Also, when an exception I create reaches the top (where I originally
called into the script with JSObjectCallAsFunction) how can I
determine the line number where the exception happened? I can't seem
to find this in the docs either. If I have to do this when I create
the exception, that is also fine.
Alas there isn't really a nice way to determine where an exception
occurred using the API, but through convention any object thrown gets
a line number and sourceURL property attached to it. When you tell
JSC to execute a script you provide the initial line number and the
url that it will attach to the exception.
You can then use normal JSC APIs to get those properties off the
exception object.
--Oliver
That will do it, thanks. I assume the property is "lineNumber", correct
(I've seen it different in different browsers.) This brings up one more
question where the docs might be more helpful -- when I need to throw an
exception, right now I just create a string JSValueRef with my
exception's description. I assume when it returns to the JSC core it's
properly wrapped into an exception object, correct? The docs are a
little bit empty on that.
Other than that (and the ongoing header/library prob, but I'll get back
to that when my port is farther) this is all pretty easy to understand
and the API is very simple and effective.
[>] Brian
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
