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@...