> body.substring(0, i + 1) + fun + body.substring(i + 1); Yuck.
Yeah. :-)
Have you guys already talked about just throwing the exception on the Java side?
I think that is what John referenced on comment 12 in the issue: "we cannot guarantee NPEs in production mode (typically you will get a JS exception, but not always as methods can be devirtualized, made static, and inlined). We could detect some subset of these in DevMode, but we couldn't catch all of them. In particular, JSO methods are frequently going to run entirely in the browser so we wouldn't get hooks to check for NPEs unless we rewrite the JS code to check and manually throw an NPE (which seems hard to get right)." I'm guessing here, but my understanding was that "null.doFoo()" could actually work in web mode if it ended up being "doFoo(null)" and the body of "doFoo" never used "this"/"this$static". So, instead of adding a Java-side null check to all JSO instance method invocations (which might cause more devmode NPEs than webmode would), I thought that this (admittedly very hacky) approach of just putting the null back and letting the JS run as-is would most match what will happen in webmode. I think. http://gwt-code-reviews.appspot.com/1620805/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
