[webkit-dev] JSC: Callback functions returning exception, what should be the JSValueRef return?

Brian Barnes ggadwa at charter.net
Tue Aug 11 11:34:19 PDT 2009


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


More information about the webkit-dev mailing list