The particular case that brought this up is that AdWords is seeing exceptions in the wild that can only stem from the 'attached' state of parents and children being inconsistent. As far as we can tell, the only way this could happen is if an exception were thrown that terminated that loop early.
On Mon, Sep 14, 2009 at 5:15 PM, Ray Ryan <[email protected]> wrote: > That's up to the app to decide. There's a good chance they're catching all > exceptions and presenting them to the user with a "Oh noes! Click here to > refresh!" button. We need to stay as viable as we can until that point. > > > On Mon, Sep 14, 2009 at 2:13 PM, Ray Cromwell <[email protected]>wrote: > >> >> It seems weird from the standpoint that in the ordinary state of affairs, >> you'd only get one exception from one detach operation and the loop would >> terminate early. I guess my question is, even with this fix, is the >> application likely to be in a good state that can keep running afterwards? >> Seems to be if an onLoad fails, the application is likely to be unable to >> recover and need a refresh in many cases, would it not? >> >> -Ray >> >> On Mon, Sep 14, 2009 at 1:53 PM, John LaBanca <[email protected]>wrote: >> >>> You don't think its a little weird to batch up exceptions and then throw >>> them? It fixes the problem for everyone, but for some reason it seems weird >>> to me. >>> >>> Thanks, >>> John LaBanca >>> [email protected] >>> >>> >>> On Mon, Sep 14, 2009 at 4:51 PM, Ray Ryan <[email protected]> wrote: >>> >>>> NM, brainfart. >>>> But I'm confused just why you're tying this to UncaughtExceptionHandler. >>>> The invariant will still go straight to hell if none has been provided, >>>> right? Also, why not fix this in a single spot rather than several >>>> scattered >>>> places? Also, it's kind of weird to catch Throwable rather than Exception. >>>> >>>> But assuming you're sure about Throwable, seems like you should instead >>>> do something like this in Panel: >>>> >>>> public class PanelDetachException extends RuntimeException { >>>> PanelDetachException(Set<Throwable> causes) { ... } >>>> Set<Throwable> getCauses() {...} >>>> } >>>> >>>> protected void doDetachChildren() { >>>> Set<Throwable> caught = new HashSet<Throwable>(); >>>> >>>> // Ensure that all child widgets are detached. >>>> for (Iterator<Widget> it = iterator(); it.hasNext();) { >>>> Widget child = it.next(); >>>> try { >>>> child.onDetach(); >>>> } catch (Throwable e) { >>>> caught.add(e); >>>> } >>>> } >>>> >>>> if (!caught.isEmpty()) { >>>> throw new PanelDetachException(caught); >>>> } >>>> } >>>> >>>> >>>> On Mon, Sep 14, 2009 at 1:35 PM, John LaBanca <[email protected]>wrote: >>>> >>>>> The uncaughtexceptionhandler is in an inner try/catch block. The outer >>>>> try/finally still runs, so we always reach the finally block. >>>>> >>>>> Thanks, >>>>> John LaBanca >>>>> [email protected] >>>>> >>>>> >>>>> On Mon, Sep 14, 2009 at 4:34 PM, John LaBanca <[email protected]>wrote: >>>>> >>>>>> What do you mean? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> John LaBanca >>>>>> [email protected] >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Sep 14, 2009 at 4:33 PM, <[email protected]> wrote: >>>>>> >>>>>>> On 2009/09/14 20:23:31, jlabanca wrote: >>>>>>> >>>>>>> >>>>>>> So the UncaughtExceptionHandler violates finally? Isn't that a pretty >>>>>>> fundamental problem? >>>>>>> >>>>>>> >>>>>>> http://gwt-code-reviews.appspot.com/64815 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
