Hi everyone,
Code compiled with the OBFUSCATED flag doesn't work anymore. We cannot reproduce the problem when PRETTY or DETAILED is used. It fails for all supported browsers in the same way.
I have tried to isolate this problem as a reproducible test case, but so far no luck.
It's very hard to find a proper mental model to understand what is actually happening inside the browser. The best I can do right now is this pseudo-code:
--- SNIP ---
public void run(String argument) {
try {
int value = parseInt(argument);
} catch (Exception e) { // (1)
log("UhOh!"); // (2)
// That's not the right argument.
...
}
}
private int parseInt(String s) throws NumberFormatException {
// Parse and fail...
}
--- SNIP ---
It starts with parseInt throwing the NumberFormatException. By tracing the flow, we can show that the catch at (1) (or the log at (2)) is never reached. Instead we exit through an error:
--- SNIP ---
java.lang.Throwable: (ReferenceError) : a is not defined
at com.google.gwt.core.client.impl.StackTraceCreator$CollectorEmulated.$fillInStackTrace(StackTraceCreator.java:174)
at com.google.gwt.core.client.JavaScriptException.JavaScriptException(JavaScriptException.java:508)
at com.google.gwt.lang.Exceptions.caught(Exceptions.java:29)
at some.Blah.$parseInt(Blah.java:...)
--- SNIP ---
And after doing a voodoo rain dance like this modification:
--- SNIP ---
public void run(String argument) {
try {
try {
int value = parseInt(argument);
} catch (Throwable t) {
log("Still flying: " + (t instanceof Exception)); // (3)
throw (Exception) t;
}
} catch (Exception e) { // (1)
log("UhOh!"); // (2)
// That's not the right argument.
...
}
}
--- SNIP ---
The "Still flying" log actually happens and t is the expected NumberFormatException. Then we re-throw and exit through the same error again, without reaching (2).
Has anyone found a technique to get a different perspective on this kind of problem?
Cheers,
Dann