What I mean is, uncaught native JS exceptions should still be caught by a
catch(Throwable) being somewhere on the stack frame. Techncially, the stack
trace wasn't lost, as it was available on
JavaScriptException.getException().stack, but I get the point, I
implemented a similar unwrap for gwt-exporter projects internally.
Actually, non-JS exceptions lose the underlying stack trace which is a
problem. If you have a stack trace that looks like this:
js func
js func
gwt func
gwt func
js func
js func
gwt func
gwt func
And the bottom gwt func does "throw new SomeJavaException()", but you let
this exception bubble up to JS, you lose the original Error.stack created
in StackTraceCreator (it is used and thrown away). StackTraceElement's
don't really model external JS functions very well. I modified Throwable
with an expando as a hack so that my subclass of CollectorChrome saves the
resulting native JS Error and unwraps it on bubbling to JS, so that the
Chrome Devtools can show something sensible, and source map tools could
deobfuscate a combined JS/Java stack trace.
On Tue, Jul 9, 2013 at 4:25 PM, Goktug Gokdogan <gok...@google.com> wrote:
>
>
>
> On Tue, Jul 9, 2013 at 2:30 PM, Ray Cromwell <cromwell...@google.com>wrote:
>
>> To me clear, if I put catch(Exception), catch(Throwable), or
>> catch(RuntimeException), I would expect to catch JavaScriptExceptions.
>>
>
> Yes, that's correct. We are not changing that.
>
>
>> I would only expect a JS exception to escape if and only if, there are
>> no catch blocks for it, or any of it's supertypes, and no uncaught
>> exception handler is installed.
>>
>>
> I'm not sure what you exactly mean. Do you mean the behavior should change
> if there are any catch blocks in the stack even the same exception
> re-thrown? I would disagree with that.
>
> It is possible to add a code to intercept and rethrow an exception. As a
> java developer, you would not expect that to change anything. However
> currently it changes the behavior.
>
> E.g.
>
> void a() {
> try {
> b();
> } catch(Exception e) {
> // some logic here, e.g. log or report the error in UI
> throw e; // throw the same e that was caught
> }
> }
> void b() {
> X x = null;
> x.toString(); // or anything else such as JSNI that causes js throw
> }
> native void someNativeCode() /*-{
> try {
> @x.y.Example::a();)
> }
> catch(e) {
> // before the fix e would have been a java object (i.e.
> JavaScriptException)
> // while calling @x.y.Example::b is a native JS TypeError.
> }
> }-*/;
>
>
> The fix I submitted basically unwraps 'e' on rethrow so putting the catch
> block doesn't change propagated exception as most developers would expect.
> In addition to that, if the exception in the example ends up escaping to
> browser, we used to lose the stack trace as it was no longer a native
> javascript exception, which is also fixed with the submitted patch.
>
> (Actually, in reality the previous behavior was even worse: If the code
> was catching any exception (e.g. IOException), it would still cause the
> same problems - having just a 'catch' was enough to break native
> exceptions.)
>
>
>>
>> On Fri, Jun 14, 2013 at 5:51 PM, Goktug Gokdogan <gok...@google.com>wrote:
>>
>>> I just wanted to give you a heads up that Roberto and I are working on a
>>> compiler patch so that catch statement will not break js originated
>>> exceptions.
>>>
>>> To give you some background, if you put any try/catch statement in Java,
>>> js originated exceptions will be converted into JavaScriptException even if
>>> you are not catching a JavaScriptException or any of its parents.
>>> Because of this problem there are workarounds in SDK to avoid catch
>>> statements if there are no UncaughtExceptionHandlers registered. By
>>> avoiding "catch" statements and repeating code, we are making sure a js
>>> exception can correctly escape and reported by the browser.
>>>
>>> Also with this patch, we can make some exceptions escape to the
>>> browser asynchronously without breaking the code flow. This is useful to
>>> fix problems like issue #6833 and similar others in the SDK.
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
