[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