Echoing offline reply for the Rietveld record:

Is there a worry that this changes the current behavior, such that =
if
anyone was relying on an early handler throwing that it would stop
subsequent handlers?

Perhaps, but it's so much more likely that people are having
mysterious
failures that I'm comfortable with the change. We've made similar
fixes
recently in our core widgets, and the results have only been good.

Ok, good.

=A0- Should HandlerManager still have an UncaughtExceptionHandler? In
my
app I'd like to be able to have a HandlerManager that won't re-throw
exceptions, so that I can send Events out and still know that,
regardless of how they're handled, my original function will
continue.

Won't that be the case with the flow I've described? All events will
fire=
,
and kick off whatever it is that they kick off, and then the collected
exceptions will be re-thrown. In most apps, I figure this will reach
the
default UCE and put up a red banner or whatever. What would this break
in
your app?

I'm thinking of code like:

  handlerManager.fireEvent(new BeforeSomethingHappensEvent());

  // do something

  handlerManager.fireEvent(new AfterSomethingHappenedEvent());


If HandlerManager just batched the exceptions and threw them at the
end, it would still prevent the "do something" from executing. I'd
want a HanderManager that was bulletproof for all exceptions,
regardless of who's listening.

Though that could probably be achieved with a subclass specific to my
code, if you don't think that it's generally useful.



http://gwt-code-reviews.appspot.com/136805

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to