@mmastrac, Thanks for the data. I think that I should add an override to JavaScriptException to handle non-java exceptions in those browsers that do have e.stack or equivalent and retain some kind of caller chain for java-dervied exceptions.
-- Bob. (Android) On Feb 13, 2009 1:25 PM, "Matt Mastracci" <matt...@mastracci.com> wrote: Bob, We've been doing the same thing for a while using a slightly different method. Some notes from our implementation: 1. The callee chain represents functions, rather than activation records as you'd expect. If you call a method re-entrantly, you'll end up in an infinite loop (a.callee -> b.callee -> c.callee -> a.callee). Our implementation uses a loop counter to prevent this from running away, but a better implementation would be testing against a set of functions that have already been seen. 2. e.stack works a lot better in Firefox, since methods that appear twice in the stack don't cause the stack trace to terminate early. 3. Argument information for non-reentrant functions is pretty reliable across browsers. It might be worth capturing the shape of parameters where the value is available (ie: [number], [HTML element], etc.) 4. Opera's caller property is unreliable in GWT web mode code and the caller chain peters out after a few iterations for some unknown reason. It has its own stack trace property on exceptions, somewhat like the one Firefox offers. On 13-Feb-09, at 11:04 AM, BobV wrote: > The attached patch implements web-mode stack traces and t... > web_stack_traces_r4689_r2 > .patch><15CD200D012CAACC790C8430C40192E8_sybolMap.properties.gz> --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-To... --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
