On Oct 1, 12:32 pm, Scott Blum <sco...@google.com> wrote: > It sounds like the problem really boils down to less-than-useful stack > traces when a native exception is thrown in Dev mode. Ironically, if you > ran this in Prod mode, you'd probably get a better stack trace, because we > emulate the stack over there. > > We could probably implement the same sort of stack trace emulation feature > in Dev mode + some other stack cleanup to make the exception traceback much > nicer.
Well, I'd say there are two problems (well three if you include the fact that this exception wasn't being thrown on 2.0.4). The first is that the stack trace is not very friendly. The second is this problem of allowing outstanding commands to keep executing even after a test has finished. Fixing the original exception would make the second problem go away but I would have been able to focus in on the first exception more quickly if it hadn't been for the secondary exceptions that occurred as a result of the first. Definitely providing more information in the stack trace would be great. For example, with a debugger, I can see that the call that was invoked (that threw the exception) is "@com.google.gwt.dom.client.DOMImplTrident::dispatchEvent(Lcom/google/ gwt/dom/client/Element;Lcom/google/gwt/dom/client/NativeEvent;)". That tells me a little more than I knew before although I don't know yet if that's useful. It's only telling me that something somewhere inside dispatchEvent threw an exception and a ReturnMessage.isException = true was returned. It would be nice to have a stack trace for the code that created this ReturnMessage in response to an exception. This may be a slight tangent, but I know that we often get these types of exceptions in production (so not dev mode here) that are caught by our uncaught exception handler and some of them don't even include a line number or file name. When your logs say an error occurred and the entire message is literally "Unspecified error", there's just no way to debug it. I thought I had heard you guys had some way of creating a stack trace of the native javascript exception and then some means of de-obfuscating it. Did I imagine that? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
