StackTraceCreator.CollectorLegacy useless for JavaScript exceptions?

[Jens]

Hi,

for some time our app has produced useless stack traces in FF, IE10+11 in case of null pointer exceptions thrown by the browser (TypeError: var is null). After some debugging I have seen that our app uses CollectorLegacy for these browsers because the GWT module had defined <set-property name="compiler.useSourceMaps" value="true"> without any condition on the user.agent value.

After taking a closer look how things work with CollectorLegacy I figured that it must always produces useless stack traces for JavaScriptExceptions and I am wondering if thats a known fact and if GWT can't handle that any better?

Whenever you have a catch block in Java, GWT generates (pseudo code):

catch ($e0) {

  $e0 = wrap($e0);

  if($e0 instanceof Throwable) { 

    execute real catch block 

  } else {

    throw unwrap($e0);

  }

}

If $e0 is a javascript exception the wrap() call creates a new GWT JavaScriptException and later on when you call getStackTrace() on that exception you will see a stack trace whose root is inside the wrap() function (exception.fnStack Array) and you won't see any of your own code in that stack trace. As an example:

Caused by: java.lang.Throwable: (TypeError) : this.A is null
	at com.google.gwt.lang.Exceptions.getCachableJavaScriptException(Exceptions.java:43)
	at com.google.gwt.lang.Exceptions.wrap(Exceptions.java:26)
	at com.google.web.bindery.event.shared.SimpleEventBus.$doFire(SimpleEventBus.java:173)
	... 10 more

In this case taken from our app above the bold line are missing 6 lines of app code that would point to the problem, however CollectorLegacy just swallows all of them because of the wrap() code.

I guess that could be VERY annoying for people supporting IE8+9.

Any thoughts?

-- J.

[Goktug Gokdogan]

On Fri, Jul 25, 2014 at 10:15 AM, Jens <jens.ne...@gmail.com> wrote:

Hi,

for some time our app has produced useless stack traces in FF, IE10+11 in case of null pointer exceptions thrown by the browser (TypeError: var is null). After some debugging I have seen that our app uses CollectorLegacy for these browsers because the GWT module had defined <set-property name="compiler.useSourceMaps" value="true"> without any condition on the user.agent value.

This is not intended and actually a bug in deferred binding. I'll send a patch. IE10+ & FF should still be using CollectorModernNoSourceMap.

 

After taking a closer look how things work with CollectorLegacy I figured that it must always produces useless stack traces for JavaScriptExceptions and I am wondering if thats a known fact and if GWT can't handle that any better?

Whenever you have a catch block in Java, GWT generates (pseudo code):

catch ($e0) {

  $e0 = wrap($e0);

  if($e0 instanceof Throwable) { 

    execute real catch block 

  } else {

    throw unwrap($e0);

  }

}

If $e0 is a javascript exception the wrap() call creates a new GWT JavaScriptException and later on when you call getStackTrace() on that exception you will see a stack trace whose root is inside the wrap() function (exception.fnStack Array) and you won't see any of your own code in that stack trace. As an example:

Caused by: java.lang.Throwable: (TypeError) : this.A is null
	at com.google.gwt.lang.Exceptions.getCachableJavaScriptException(Exceptions.java:43)
	at com.google.gwt.lang.Exceptions.wrap(Exceptions.java:26)
	at com.google.web.bindery.event.shared.SimpleEventBus.$doFire(SimpleEventBus.java:173)
	... 10 more

In this case taken from our app above the bold line are missing 6 lines of app code that would point to the problem, however CollectorLegacy just swallows all of them because of the wrap() code.

You cannot swallow something that doesn't exist :) For browsers without stack support (ie8/9, safari5) and without stack emulation enabled, we don't have any options but crawl and construct the call stack by ourselves (i.e. CollectorLegacy). We can only do at the time we catch the exception - in this case EventBus. Unless we generate try/catch blocks to every statements, that's all we could get from these old browsers - in that case it just better to enable stack emulation.

 

I guess that could be VERY annoying for people supporting IE8+9.

Any thoughts?

-- J.

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/fb58dcd4-16cf-4e96-81a3-54ce295d550f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jens]

This is not intended and actually a bug in deferred binding. I'll send a patch. IE10+ & FF should still be using CollectorModernNoSourceMap.

Ok cool. Is there a good reason why IE 11 and FF should not use CollectorModern yet? 

-- J.

[Goktug Gokdogan]

On Fri, Jul 25, 2014 at 3:12 PM, Jens <jens.ne...@gmail.com> wrote:

This is not intended and actually a bug in deferred binding. I'll send a patch. IE10+ & FF should still be using CollectorModernNoSourceMap.

Ok cool. Is there a good reason why IE 11 and FF should not use CollectorModern yet? 

No good reasons mostly lack of testing and my time :(

From top of my head, following is what we need to enable them safely:

 - We need to put test in place that tests the line numbers. (Roberto has a stale patch)

 - We need to server (StackTraceDeobfuscator) to decide on using line numbers from symbol map or sourcemap not the client.

 - We are missing automated testing on IE11 so somebody needs to them with combinations (sourcemap enabled/disabled).

 

-- J.

--
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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/2dcb3ace-2a16-41ef-8519-6a305859025c%40googlegroups.com.