commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [collection] Collections for primitives
Date Sat, 22 Jun 2002 23:06:22 GMT
From: "Michael A. Smith" <>
> On Sat, 22 Jun 2002, Stephen Colebourne wrote:
> > I agree with Ola's views below. add()s should throw a
> > remove()s should be silent. queries should return false. The collection
> > just much easier to use that way. And all of this behaviour should be
> > documented.
> My biggest concern with Ola's views is that ignoring the incompatible
> class being passed as an argument is (in my opinion) almost guarunteed
> to be a programming error that will be masked, making debugging a
> problem difficult.  Can you provide a use-case where such a behavior is
> desirable and isn't a defect in the program (either a design defect or
> an implementation defect)?  If I knew in what context the maps were
> planning on being used where type-safety shouldn't be quite as strict,
> then I'd have an easier time accepting a change in the behavior.

For me, the method contains(Object) means "does this collection contain this
object - yes or no". I see no role for ClassCastException here. Just return
no. Same argument for indexOf/remove

The use case is where the List has been passed into another method as a List
(interface) rather than the class. Then the code in that method doesn't know
that this is some special type of list. The coder of that method won't be
expecting ClassCastExceptions from contains/indexOf/remove. They should
expect the exception from add. Its not just about the spec, its also about
common practice.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message