JSC: Callback functions returning exception, what should be the JSValueRef return?
When I define a callback function (JSObjectCallAsFunctionCallback), and I have it thrown an exception, what should be the return value? The documentation says: "A JSObject that is the constructor's return value" ... but the other side -- JSObjectCallAsFunction -- states: "The JSValue that results from calling object as a function, or NULL if an exception is thrown or object is not a function." So should I also be returning NULL from my callback functions if I'm throwing an exception? If so, you should probably improve the documentation there. [>] Brian
The design is that the return value is ignored. In theory, you can safely return anything, even a garbage pointer. -- Darin
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. [>] Brian
On Aug 11, 2009, at 11:13 AM, Brian Barnes wrote:
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?
Yes.
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?
Someone more familiar with it may be able to confirm or deny this, but I’m pretty sure that the public API does not give you a way to find out the URLs and line numbers involved in an exception. The URL, line number, and other data about the call stack is communicated to the debugger for example, but while the API gives you a way to pass these in, it doesn’t give you a way to see them when an exception comes out. That’s something we could add in a future version of the API. Of course, if the exception is happening inside your C or C++ code, then there’s no real JavaScript line number for that, so I presume you’re asking for the URL and line number of the first bit of JavaScript that was on the call stack at the time the exception was created. Maybe the entire call stack would be useful too. -- Darin
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
[>] Brian
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
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
I feel bad that we didn't move this to webkit-help. This list is supposed to be for development of WebKit. While that list is for help using WebKit. On Aug 11, 2009, at 11:34 AM, Brian Barnes wrote:
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?
Since the JavaScript language lets you throw any value as an exception, so does the JavaScriptCore API. If you want an object for your exception, one that will end up with line number properties and the like, then you’ll need to create one. The API won’t make it for you. The objects that are thrown by the engine itself are Error objects, but there's no real need for you to use that prototype. You could throw almost any kind of object. I suggest just creating one with JSObjectMake and NULL for the class. And you could attach a message with the property name "message" to be a bit like an Error object. -- Darin
On Aug 11, 2009, at 11:40 AM, Darin Adler wrote:
Since the JavaScript language lets you throw any value as an exception, so does the JavaScriptCore API.
If you want an object for your exception, one that will end up with line number properties and the like, then you’ll need to create one. The API won’t make it for you.
The objects that are thrown by the engine itself are Error objects, but there's no real need for you to use that prototype. You could throw almost any kind of object. I suggest just creating one with JSObjectMake and NULL for the class. And you could attach a message with the property name "message" to be a bit like an Error object.
I consider this to actually be a bug in the engine -- there should be some sane way to get information about an exception without depending on the exception value itself. --Oliver
participants (3)
-
Brian Barnes
-
Darin Adler
-
Oliver Hunt