Would always on mean that it generates code even for browsers that have
native stack traces (i.e. FF)?
Yes, for the purpose of giving you consistency between browsers.
Generally, as much as I hate to say it, it seems we'd want variations of the
tests both with and without stack trace code,
Technically, wouldn't it just mean we should not pin down the value of the
deferred binding property that controls it? It would double the number of
permutations, tho.
But wouldn't we actually want to run the instrumented code, to make
sure that the instrumentation itself doesn't break
Yes, I think we would want to. My point is that we also would want to run
the non-instrumented code. I have to think there could be subtle downstream
behavioral differences (e.g. compiler optimizations that do/don't happen)
based on whether the stack trace code is generated. Thus, I'm saying we
On Thu, Jul 23, 2009 at 1:25 PM, Bruce Johnsonbr...@google.com wrote:
Yes, I think we would want to. My point is that we also would want to run
the non-instrumented code. I have to think there could be subtle downstream
behavioral differences (e.g. compiler optimizations that do/don't happen)
@Bruce,
Per our phone conversation, JUnit will turn on the emulated stack
trace code for browsers that do not provide stack data for native
exceptions.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
Here's a null-pointer deref in Safari. The location data here is
accurate, you can call up RequestBuilder.java and see on line 396 that
it's firing onResponseReceived.
The offending Java code is: ((String) null).charAt(55);
The exception reported through the JUnit console is
As soon as we can auto-translated symbols, this will be awesome!
On Thu, Jul 23, 2009 at 4:11 PM, BobV b...@google.com wrote:
Here's a null-pointer deref in Safari. The location data here is
accurate, you can call up RequestBuilder.java and see on line 396 that
it's firing
Committed at r5779.
If anyone is interested in testing this out, you can take a look at or
just inherit com.google.gwt.core.EmulateJsStack. Right now, this is
kind of a blunt instrument, but the control mechanism will be refined
with the addition of module property predicates.
--
Bob Vawter
On Wed, Jul 22, 2009 at 4:46 PM, BobV b...@google.com wrote:
Should running a web-mode test case always turn on the emulated stack
trace code?
You would get stack traces entries like:
Unknown.bx(YourClass.java:1234) regardless of which browser you're on
and the type of exception,
On Wed, Jul 22, 2009 at 4:57 PM, Scott Blum sco...@google.com wrote:
On Wed, Jul 22, 2009 at 4:46 PM, BobV b...@google.com wrote:
Should running a web-mode test case always turn on the emulated stack
trace code?
Would always on mean that it generates code even for browsers that have
native
10 matches
Mail list logo
