commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <>
Subject RE: [collection] Collections for primitives
Date Tue, 25 Jun 2002 15:24:31 GMT
I can see merit in both permissive and fail-fast 
implementations, though I tend to favor the permissive

However, it bothers me that current the Predicate 
collections use the permissive approach but the 
primitive collections use the fail-fast approach.

For consistency's sake, I'd like to see consensus and
rewrite one or the other.  

Middle ground might be acheived by having Predicate
use fail-fast collections, but providing another set
of decorators that automatically translates raised
exceptions into false results...or something...


> -----Original Message-----
> From: Ola Berg []
> Sent: Saturday, June 22, 2002 4:23 PM
> To:
> Subject: Re: [collection] Collections for primitives
> michael wrote:
> >In my opinion, if you\'re asking an int based collection for the
> >presence of a String, it\'s an error in your program and warrants the
> >throwing of an exception (ClassCastException) at runtime.
> The problem is that it is runtime type checking. If you adhere to the
> principle that the exception should be unchecked if the exception
> could be avoided by the programmer (like NullPointerException), a
> ClassCastException is cruel, as you have no idea (given a List) that
> the collection is type-safe and that the type safety is asserted via
> ClassCastExceptions even in the lookup methods.
> This is actually an argument against the parts of the Collection
> contract in the first place. Given any List, you have no way of
> telling if it is going to throw ClassCastExceptions or not, except by
> trying. Just as you don\'t know if it supports any of the optional
> methods (adding etc). Which means that you in reality has to check and
> deal with all four unchecked exceptions (IllegalArgument,
> UnsupportedOperation, ClassCast, NullPointer) when using any of the
> basic collection methods on any List you don\'t know the implementing
> class for.
> But since we cannot change the contract, we can at least do the best
> of it. Asking an int based collection for a String is most certainly
> wrong. But asking _any_ collection (typed or not, you just 
> don\'t know)
> for a String can\'t be wrong. Or asking any collection for the
> existence of any object regardless of type. Type safe collections are
> special, I agree to that. But I see no reason to make them more
> special than needed.
> With the path chosen, the number of runtime checks becomes a burden
> for the user of the API. I might not know what List implementation I
> have in my hand, and the idea with common interfaces is that I
> or my API:s really shouldn\'t need to know.
> Throwing ClassCastException when adding might be needed for type
> safety. But for lookups it really isn\'t necessary. 
> Especially when you
> have collections with elements of different types in it.
> Permissive and fail-safe approaches has their places, just as the
> strict and asserting has. If the type-safe classes in
> Commons Collection all takes the (unnecessary) strict approach, I
> would say that there is a need for more permissive ones. And in order
> to reduce duplication of effort, I suggest that the strict approach is
> implemented through decoration of the permissive ones, as the other
> way around is impossible.
> >If you
> >think an addition to the documentation is warranted even though the
> >contract states it might be thrown when an ineligible element is
> >passed, then please post a patch to that effect.
> Just because the contract states that it _might_ be thrown, the
> behaviour _should_ be documented, regardless of what path the
> Collections component choses to take. Just as a well
> documented read-only collection states that the modifying operations
> are unsupported and will result in an exception.
> I will gladly supply the patch, but I am also interested in other\'s
> opinion on this.
> /O
> --------------------
> 0733 - 99 99 17
> --
> To unsubscribe, e-mail:   
For additional commands, e-mail:

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

View raw message