[concurrency-interest] LinkedBlockingQueue does not throwNullPointerException for the method call contains

Szabolcs Ferenczi szabolcs.ferenczi at gmail.com
Sun Apr 15 20:21:33 EDT 2007

On 16/04/07, David Holmes <dcholmes at optusnet.com.au> wrote:
> I can't see what threading has to do with whether a method throws an
> exception or not.
> In the case of contains(null) it really boils down to whether asking for
> something that can't possibly be there is a "silly question" that should
> just be ignored (ie return false), or whether it indicates a serious flaw in
> the caller because the caller should never have presented a null in the
> first place - and so throw an Exception.

Well, in this case threading does not really plays role. In this case
the data structure does not allow for null and if query is about a
null item, it should result in the same behavior as when the null item
is attempted to be inserted --- exception.

I really made this remark for the case if an exception is thrown when
a query is unsuccessful for the moment. But it is not the case with

> > Besides, I see major problems with this method in case of a shared
> > data structure as well as with other methods that shared classes
> > inherit from sequential classes.
> Any query method has limits in a concurrent context. That doesn't mean they
> aren't useful, it just means the limits have to be understood. Ultimately it
> how an application uses the data structure that determines what makes sense
> and what does not. The data structure provides an API that is as general as
> possible to account for as many use-cases as is reasonable.

I am curious when a query such as "contains(youCanHaveThisItem)" is
useful in a concurrent context. Remember---in a concurrent context. It
may be useful in a single threaded environment where it is guarantied
that the subsequent get will find it there but you can do nothing with
this query in a multi-threaded case, do you?

Best Regards,

More information about the Concurrency-interest mailing list