Community
Participate
Working Groups
Anywhere we use a collection and call collection.remove(), we need to check that the expected object was found and removed by the collection. In this situation, we should throw an exception. The #1 cause of hard to find data binding bugs has been an incorrect equals() or hashCode() implementation. We have spent literally days on a couple of bugs tracing through our code and through data binding when our overall algorithm was perfect and there was no bug in data binding. In both of these cases the bug turned out to be some quirk or something just wrong about our equals() or hashCode() implementation in a domain object. If an exception was always thrown when data binding tried to remove an object and couldn't (perhaps with a message "check your equals() and hashCode() methods"), we would have failed fast rather than have a hard-to-find bug.
-1 We'd be changing the contract of List by doing this. There are use cases where the consumer doesn't care if the item was found and changing this changes assumptions that are already in place and limits the ability of hiding the implementation. I don't necessarily have a recommendation for how to resolve this yet but I don't think changing remove() is the way to go.
Dave, could you point us to places in the current code (or one example) where we call remove and should check for the returned object? I looked at ListBinding and it works based on indices, not elements, so it seems that you are talking about the not-yet-existing SetBinding?
Ah, so I think I misunderstood your intentions. If you're saying in bindings we need to check this that's a different story altogether. :)
I'm not sure of the current code's status, but in the ListBinding implementation we have here at TPC, there are still some places where we just call list.remove() when applying the ListDiff. The intent of filing the bug was mostly as a "note to self", make sure we get this right in the future or we'll have people asking on the newsgroup why data binding isn't working when the problem is really their equals/hashCode implementations.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
