[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
On Thursday, July 18, 2013 3:21:59 PM UTC+2, RyanZA wrote: Jens, even with source maps in Chrome, I've been unable to get stack traces to work. They still print out poorly in production when an exception is hit - the exceptions ignore the source maps entirely. I asked previously if there is a way around it, but apparently it's a known issue - so I don't think SourceMaps solve this problem yet. That said, the size and speed overhead here is terrible and most people would avoid something that adds that much overhead in production (although it would be great in development). What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads. I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution. This is what the StackTraceDeobfuscator does already. It's currently based on symbolMaps (GWT-specific) rather than source maps though. -- 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.
[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
That article was the third result in a Google search for gwt web mode exceptions: http://www.summa-tech.com/blog/2012/06/11/7-tips-for-exception-handling-in-gwt/ I agree that http://www.gwtproject.org/doc/latest/DevGuideLogging.html#Remote_Logging needs to be expanded. On Thursday, July 18, 2013 3:38:15 PM UTC+2, RyanZA wrote: Hi Thomas, It would be great if you (or anybody who understands how to set it up) could add a small article on gwtproject.org about setting up the different methods of getting stack traces in production on exceptions? Thanks! Ryan On Thu, Jul 18, 2013 at 3:30 PM, Thomas Broyer t.br...@gmail.comjavascript: wrote: On Thursday, July 18, 2013 3:21:59 PM UTC+2, RyanZA wrote: Jens, even with source maps in Chrome, I've been unable to get stack traces to work. They still print out poorly in production when an exception is hit - the exceptions ignore the source maps entirely. I asked previously if there is a way around it, but apparently it's a known issue - so I don't think SourceMaps solve this problem yet. That said, the size and speed overhead here is terrible and most people would avoid something that adds that much overhead in production (although it would be great in development). What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads. I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution. This is what the StackTraceDeobfuscator does already. It's currently based on symbolMaps (GWT-specific) rather than source maps though. -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/1qDVlPGryKo/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com javascript:. To post to this group, send email to google-we...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/google-web-toolkit. 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.
[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
What GWT needs here is something closer to what you get with proguard - a mapping file created during compilation that could be used to run the obfuscated/javascript exception through a utility to give the correct stack trace with zero overheads. I'm not entirely sure on how proguard accomplishes it, but I'd say it would be the perfect solution. We also do not use emulated stack traces because of performance and code size overhead. So we simply deploy the symbol maps generated by GWT compiler and use StackTraceDeobfuscator on the server. We also extended StackTraceDeobfuscator a bit because we received exceptions where the stack trace is actually inside the exception message instead of the exception stack trace (the exception stack trace was empty). So we try to deobfuscate the exception message as well in this case. Given the above the quality of stack traces now depends on the browser version our clients use. We do not support IE6/7 and IE 8 support will be dropped next year (regardless of what GWT does). So we mainly deal with newer browsers and we pretty much always get deobfuscated stack traces that provide some useful information. Its not perfect but it works. We never get the concrete line number where the exception occurs but we often enough have the method name. Of course sometimes we have no stack information at all (IE8). In addition you can enhance the stack trace by providing additional client information. For example you could send the current URL to the server which tells your the current place state if you use GWT Places. You could also implement a custom Logging Handler that logs into a ring buffer and once a client exception occurs you send the last x client log entries along with the stack trace. Or if you do not want to enable logging itself in production you could still use the ring buffer approach and store user actions in it and then send these to the server (similar to client side logging). Or you trace user click coordinates and their underlying elements (event preview handler) So before enabling full stack trace emulation in GWT you can do quite a few things to get information about what has happened inside the app once the exception had occurred. Btw. we stopped using SourceMaps for Chrome because for whatever reasons StackTraceDeobfuscator has imports from gwt-dev.jar that are needed when SourceMaps are enabled. -- J. -- 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.
[gwt-contrib] Re: I'm enhancing GWT to provide Java stack traces for clientside exceptions in production
In response to some of the concerns expressed in this thread, I'd like to clarify that by using my patch, you will not be making any trade-offs versus what you previously had with GWT's old implementation: my patch will give you all pros and no cons. Here's why: There are two ways to get perfect stack traces in production: 1) via a compiler-generated source map file in a browser that provides JS stack traces with column numbers (only Chrome right now) and 2) via stack emulation for all other browsers. My project implements both solutions, along with lots of improvements to their existing implementations in GWT. So if anyone is already using any of the following: stack emulation, symbol maps, source maps, StackTraceDeobfuscator, etc., my patch will make those things better for you without requiring you to use other pieces that you don't need. For example, you could configure it to only use solution #1: which gives you perfect stack traces for Chrome and doesn't increase the size of your code. Or you could additionally enable solution #2, which will cover all the other browsers, with only 45% overhead in code size for those other browsers. Personally, I think that 45% is totally worth it (especially compared to the 100% overhead incurred in the original solution), and I'm using it in my app, but if you don't want any overhead, you can just take the freebie for Chrome and leave the rest as before. By the way, who wants to try it? Please get it touch with me (alex at typeracer.com), and I will email you my patch so you can see for yourself how awesome it is. -- 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.
