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.
- 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 could subclass HandlerManager and override its fireEvent method to wrap it in a try/catch, but I'm worried that with that strategy the event.kill() and event.setSource() calls at the very end wouldn't get called if a handler threw (unless I suppose HandlerManager saved its umbrella exception to throw after those lines are executed).
Exactly, that's the intent. Protect the full event dispatch cycle, and then throw up. http://gwt-code-reviews.appspot.com/136805 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
