Stephen
Thanks; but certainly the BlockingBuffer should document this use of
BufferUnderflowException, as it is clearly a misnomer for what really
happened; I suppose you have to use an exception which was available
in the interface.
- Pito
On Jun 17, 2005, at 6:30 PM, Stephen Colebourne wrote:
Pito Salas wrote:
commons.collections.buffer.BlockingBuffer throws
BufferUnderflowException
Why does that make sense? I would think that a BlockingBuffer
cannot underflow on a get().
So, an InterruptedException is turned into a
BufferUnderflowException.
Usually InterruptedException is just re-thrown. I don't
understand how to interpret the conversion to a
BufferUnderflowException, and whether I can / should safely
ignore it.
Buffer.get() can throw the underflow exception, as documented:
@throws BufferUnderflowException if the buffer is empty
For BlockingBuffer, you would not normally expect to receive the
underflow exception as the class waits for more data. However, if
it receives an interrupted exception while waiting we must handle
it. We could:
a) silently ignore it (bad)
b) log it (but collections doesn't use logging)
c) throw it
We chose (c), and as InterruptedException is not runtime, it is
wrapped in a BufferUnderflowException.
You ask if you will receive it. Well, you will if you get a
InterruptedException during the wait. I can't really be more
precise than that.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
