On 2010/08/02 19:30:20, zundel wrote:
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.
I think that's a separate issue. Even with the correct flow of start and
end calls in the code, an exception thrown further up the stack will
cause all the events on the stack to be missed. Regardless, I would
support that refactoring.
http://gwt-code-reviews.appspot.com/674805/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
