http://gwt-code-reviews.appspot.com/674805/diff/1/2
File
dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java
(right):
http://gwt-code-reviews.appspot.com/674805/diff/1/2#newcode310
dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java:310:
On 2010/08/02 19:23:37, conroy wrote:
On 2010/08/02 18:48:27, zundel wrote:
> This is no worse than before, and certainly it is not throwing
exceptions
which
> I am sure causes grief, but I want to publicly note that it isn't
guaranteed
to
> safely unwind the stack. (I've been using the logger to nest
events of the
> same type)
True. I don't think it's possible to safely unwind in that case.
Ultimately, an
unwind should make us suspicious of the timing data but it shouldn't
invalidate
the whole data set and it certainly shouldn't stop someone from
continuing to
run development mode.
The sure fire way to unroll is through the try{ } finally{ } blocks
that
currently adorn much of the instrumentation. At least with this patch,
a missed
try{ } finally { } is not a show-stopper. Would you be more
comfortable if every
ST logging call was wrapped with such a block?
P.S.
We could easily add a hintlet for such "Missed" nodes and mark them in
the ST
visualization.
my thought is that if we are going to ask the user to pass the right
event type to 'end()', then we could ask them to return the correct
stack item instead.
LogEntry entry = SpeedTracerLogger.start(...);
...
SpeedTracerLogger.end(entry);
or just entry.end();
which should always unwind correctly.
http://gwt-code-reviews.appspot.com/674805/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
