We have implemented a general mechanism that logs on the server exceptions from the GWT client side. Naturally, some of them are unexpected exceptions (such as NPE), and therefore we are getting kind of these stack traces in our log (an excerpt):
java.lang.Throwable: One or more exceptions caught, see full set in UmbrellaException#getCauses at Unknown.Hq(Unknown Source) at Unknown.ihb(Unknown Source) at Unknown.anonymous(Unknown Source) at Unknown.anonymous(Unknown Source) at Unknown.anonymous(Unknown Source) Caused by: java.lang.Throwable: (TypeError): d is null stack: EG([object Object],[object Object])@http://domain/path/0B15791BA99231E6B88EAF3BDE38EB64.cache.html:3282 fileName: http://domain/path/0B15791BA99231E6B88EAF3BDE38EB64.cache.html lineNumber: 3282 at Unknown.EG(Unknown Source) at Unknown.DG(Unknown Source)
How can I find the class and line number in the original java source?
I don't want to deploy a detailed compiled version, since I don't have information about the exact scenario and I can't reproduce the exception.
We can obtain a stack trace from a thread by calling the getStackTrace() method on the Thread instance. It returns an array of StackTraceElement, from which details about stack frames of the thread can be found.
To read this stack trace, start at the top with the Exception's type - ArithmeticException and message The denominator must not be zero . This gives an idea of what went wrong, but to discover what code caused the Exception, skip down the stack trace looking for something in the package com.
You can easily see the stack trace in JavaScript by adding the following into your code: console. trace(); And you'll get an outputted stack trace.
This also implies that a stack trace is printed top-down. The stack trace first prints the function call that caused the error and then prints the previous underlying calls that led up to the faulty call. Therefore, reading the first line of the stack trace shows you the exact function call that threw an error.
The GWT compiler outputs the mapping in symbolMap files in the -deploy
and -extra
locations (where -deploy
defaults to the -war
's WEB-INF/deploy
, and -extra
is not emitted by default).
I use it manually to debug weird things from time to time.
You can also deobfuscate traces programmatically, using the StackTraceDeobfuscator
.
FYI, this class is used by the RemoteLoggingServiceImpl
GWT-RPC servlet and the Logging
RequestFactory service; respectively called by the SimpleRemoteLogHandler
and RequestFactoryLogHandler
(they're java.util.logging.LogHandler
s which you can use with the logging API that GWT supports). In this case, it looks into the WEB-INF/deploy
of the webapp (which is why -deploy
defaults there).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With