Bug 203401 – [GLIB] Clear JSCContext exception before evaluating new code

• Status: NEW
• Component: JavaScriptCore

[Milan Crha]

This is more a question than a request:

Should the jsc_context_evaluate_* functions clear the context's exception (jsc_context_clear_exception()) before running the new code?

The use case:

I read multiple files into the context using jsc_context_evaluate_with_source_uri(). I do not check the result, it's not interesting for me in this case, but I check jsc_context_get_exception() after the call and if it is set, then I print it on the console, thinking that it belongs to the last call. The thing is, when the load of the first file fails with an exception, I print the same exception for the other files as well, even they do not belong to them.

I can call jsc_context_clear_exception() after such each exception print (and I will), but I'm think it would be better if JSCContext takes care of the exception on its own.

Similarly with webkit_web_view_run_javascript(), it should clear the exception before the code is called too, I believe.

[Adrian Perez]

Currently we do not have any hint in the API documentation
about this. Basically: whether the exception is cleared or
not by jsc_context_evaluate_* is undefined.

I think that the proposal makes sense, but technically that
implies changing the behaviour of existing public API. To me
it looks unlikely that we would break applications with the
change: I would expect that applications that check for
exceptions after calls to evaluate JS code are already calling
jsc_context_clear_exception() and doing that implicitly at the
beginning of jsc_context_evaluate_* functions will just be a
no-op for those apps; and in the other hands new applications
can use the API in a more convenient way.

As this would be a change in the behaviour (even if small)
I think we need to be careful. I have CC'd Carlos García to
have a second opinion on this.

At any rate, thanks for the suggestion!

[Adrian Perez]

For the record: in the worst case scenario in which we determine
that it is safer to NOT do this change from an API backwards
compatibility point of view, it would still be valuable to add
a note to the documentation. In that case we could take this as
an improvement to do when we do the next API/ABI break.

[Carlos Garcia Campos]

Sorry for the delay to reply. let me clarify how this is supposed to work:

What jsc_context_get_exception() is the last unhandled (or uncaught) exception. You can handle exceptions in two different ways:
 1- Just checking if there's an uncaught exception after a call, and then calling jsc_context_clear_exception() to indicate it has been handled. Or you can avoid calling the clear() is you just checked the exception but didn't actually handled it.

 2- By pushing an exception handler with jsc_context_push_exception_handler(). In this case, the exception is considered to be handled by the handler, but if you don't want to handle it you can call jsc_context_throw_exception() from the callback to indicate it hasn't been handled.

I suggest you to use jsc_context_push_exception_handler() is that's more convenient to you for handling exceptions.

[Milan Crha]

(In reply to Carlos Garcia Campos from comment #3)
> let me clarify how this is supposed to work:

Ah, I see, I didn't know that.

(In reply to Adrian Perez from comment #2)
> it would still be valuable to add a note to the documentation.

Right, that would be sufficient for me. Just to know what is expected.

My initial suggestion was (also) about convenience, but if there will be written that the exceptions are "persistent between different JSC calls", then I'm fine with it.