Re: ConcurrentModificationException, Cannot begin a new event ... - reproducible

>
> I completely agree. It seems to me it should be possible to make a "mistake"
> without getting the entire list system out of order. Normal java lists just
> continue to work even if you mess up the index (after throwing an exception
> of course).
>
> Unless there's a big reason why the commit can't finish despite the error,
> it seems to me this would be an easy fix and at least you'd get the lists
> back on track. Now I have to explicitly check indexes before a set just so
> that I never get an IndexOutOfBounds exception, as if I get one, then I
> can't use the lists anymore.
>
> Emil
>
>
> Endre Stølsvik-8 wrote:
> >
> > I've been wondering about this: shouldn't the beginEvent-commitEvent
> > always be in a try-finally block? This to contain any errors as best
> > one can? It seems to me like any error anywhere in the pipeline now
> > will lead to an irreparably inconsistent state, while if one had
> > try-finally, with the updates.["change"] always after the actual data
> > change invocation method, one would get something that at least in
> > several situations resembles a transaction with both commit and
> > rollback semantics.
> >
> > This would be so that even though there are some logic errors to could
> > come up in certain situations, the application using GL would still
> > have a chance of being consistent after an error - of being able to
> > recover out of errors.
> >
> > Endre.
> >
> > On Sun, Apr 26, 2009 at 11:06, Holger Brands <hbrands@...> wrote:
> >>  > Is this the expected behavior?
> >>
> >> Yes, with the current implementation, that's expected.
> >> If you dive into the implementation you'll see this:
> >>
> >>    public E set(int index, E element) {
> >>        // create the change event
> >>        updates.beginEvent();
> >>        // do the actual set
> >>        E previous = data.set(index, element);
> >>        // fire the event
> >>        updates.elementUpdated(index, previous);
> >>        updates.commitEvent();
> >>        return previous;
> >>    }
> >>
> >> Event delivery is guarded by calls to
> >> ListEventAssembler.beginEvent() - start recording changes
> >> and
> >> ListEventAssembler.commitEvent() - propagate recorded changes
> >>
> >> When an uncaught exception is thrown inbetween, commitEvent()
> >> is never called and no change events are fired.
> >> With the next call to beginEvent() the ListEventAssembler detects,
> >> that an event delivery is in progress leading to the
> >> ConcurrentModificationExceptions
> >> you observed.
> >>
> >> Holger
> >> __________________________________________________________________________
> >> Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
> >> ausländische Netze zum gleichen Preis!
> >> https://produkte.web.de/webde_sms/sms
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/ConcurrentModificationException%2C-Cannot-begin-a-new-event-...---reproducible-tp23172207p23241485.html
> Sent from the GlazedLists - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>