Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify list behavior in concurrent modification cases #442

Closed
ghost opened this issue Nov 14, 2011 · 2 comments
Closed

Clarify list behavior in concurrent modification cases #442

ghost opened this issue Nov 14, 2011 · 2 comments
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries.

Comments

@ghost
Copy link

ghost commented Nov 14, 2011

Should we throw a ConcurrentModificationException if a list is modified in such a way that an active iteration becomes corrupted?

See implementation of DoubleLinkedQueue.

@DartBot
Copy link

DartBot commented Nov 15, 2011

This comment was originally written by [email protected]


When designing the libraries, we decided not to do defensive checks in the iterators and iteration methods in case the collection is changed while iterating. That may be poorly documented though.

The rationale behind that decision is that we expect most uses of iteration methods to not require these checks. And we don't want to pay the price of runtime checks due to a minority of uses.

So when a concurrent modification happens, the behavior is unspecified.

@madsager
Copy link
Contributor

Comment updated to state that the behavior is unspecified if the object iterated over is changed during iteration.


Added Fixed label.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries.
Projects
None yet
Development

No branches or pull requests

2 participants