commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <ola.b...@arkitema.se>
Subject Re: [collection] Collections for primitives
Date Sat, 22 Jun 2002 23:23:29 GMT
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

--------------------
ola.berg@arkitema.se
0733 - 99 99 17

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message