1

I am writing a custom queue implementing the queue interface. This implementation is thread safe and blocks on certain occasions.

The normal Queue interface does not mention Exceptions, therefore I can't throw any InterruptedException in my implementation.

I see two solutions for this problem, but they are both not very satisfying:

  1. Remove the Queue interface and throw Exceptions. This makes the code unusable for foreign software that requires a Queue.

  2. Throw RuntimeException, this will yield tonnes of very surprising software activity, which I don't want to risk.

Somehow implementations like ArrayBlockingQueue manage to implement Queue and BlockingQueue. Is that the way to go, or what is the trick here?

Prince John Wesley
  • 62,492
  • 12
  • 87
  • 94
Franz Kafka
  • 10,623
  • 20
  • 93
  • 149
  • 1
    If your code needs to throw the exception then you'll have to make due with a `RuntimeException`. If not then you'll have to recover from the exception and retry or something. I don't see any easy answer here. In the case of `InterruptedException`, I usually just do a `Thread.currentThread().interrupt()` and then exit the thread. – Gray Oct 29 '11 at 01:26
  • what methods specifically are you concerned about? – jtahlborn Oct 29 '11 at 01:32
  • 2
    Out of curiosity, would you mind sharing your use case, in which none of the existing concurrent collections work for you? – Bruno Reis Oct 29 '11 at 03:09
  • I am writing a BoundedBlockingQueue taking any kind of queue as argument. I only found a scala implemenation, so I am writing a java one. I especially want to offer a feature for changing the bound during runtime. – Franz Kafka Oct 29 '11 at 11:01
  • For future reference: An `ArrayBlockingQueue` is always bounded, but the capacity cannot be changed at runtime. Similarly, a `LinkedBlockingQueue` may be bounded, but still does not allow the capacity to be changed. My intuition tells me that the `LinkedBlockingQueue` would be a good candidate for modifying to obtain the desired behavior. – Tim Bender Mar 13 '13 at 18:03

2 Answers2

2

If you are implementing a Queue which may need to throw an InterruptedException then my guess is that you really want to implement a BlockingQueue. If you read the javadoc for this interface, you will realize that the Java language designers have basically said that in the context of a BlockingQueue the normal Queue operations will either succeed or fail immediately. The Queue interface provides for throwing an IllegalStateException if the add method can not succeed or returning false if the offer method fails. New methods put and take as well as an overloaded variant of offer and poll are introduced by the BlockingQueue interface for operations that may block and therefor need to throw an InterruptedException.

Tim Bender
  • 20,112
  • 2
  • 49
  • 58
1

You should go with option one.

When people want to have a Queue (interface) on their hand they will expect the queue to work a certain way. The behavior is specified in the interface and the client do not need to worry about the implementation or make changes when they switch.

This is not the case with your queue, if you implement this interface but throws run-time exception you will be breaking the expectation of your client in an unexpected manner. The foreign software asks for a Queue precisely because they don't want to be "tricked" to get something non-interchangeable.

Better to make this explicit by not implementing Queue, unless you can handle the interrupted exception transparently within your object.

Desmond Zhou
  • 1,369
  • 1
  • 11
  • 18