Advertisements

On 9/25/2012 6:25 AM, wrote:
> Is there a recommended way of "chaining" interrupted exceptions?
>
> This is to implement a method call that doesn't throw an interrupted exception, but which calls a method which can be interrupted.
>
> public void uninterruptableWait(Object c) {

(Aside: `InterrupttttttttttttttttttttedException'.)
> interrupted = true;
> }
> }
> }
> if (interrupted) {
> Thread.currentThread().interrupt();
> }
> }
>
> If that interrupt was unexpected, and causes a stack trace, then it would be nice if it could include the details from the thrown exception.
>
> Is there a better way to do the above?

It seems you're trying to have things both ways: You "expect"
the interrupt by catching it, but then want to consider it as
"unexpected" anyhow. Also, you want to inform your caller but
have chosen not to throw an informative exception.

Since an exception is just an object, I suppose you *could*
have the method return it, or return `null' if there was none:

Advertisements

On 9/25/2012 3:25 AM, wrote:
> Is there a recommended way of "chaining" interrupted exceptions?

I mostly agree with Eric. You shouldn't suppress interrupts unless you
must. If for example you are implementing a Runnable, you can't throw
InterruptedException but must deal with it somehow. Then catching an
interrupted exception is reasonable.

In this case however it's 100% your code and you could throw
InterruptedException. That would defeat the purpose of the code you
show, of course, but then that is also our point: what you are doing is
rather questionable.

There's no standard pattern for this because it's not done. I'd say the
closest we have to to use a finally block to make certain the interrupt
flag is restored.

If you really need the details of the exception but can't throw from
your local use site, I'd say wrapping the exception in a
RuntimeExcpetion and throwing that is best. (Exception don't ever
throwing RuntimeException; subclass it and throw your specific exception.)

On 9/25/12 3:25 AM, wrote:
> Is there a recommended way of "chaining" interrupted exceptions?
>
> This is to implement a method call that doesn't throw an interrupted exception, but which calls a method which can be interrupted.
>
> public void uninterruptableWait(Object c) {
> boolean done = false;
> boolean interrupted = false;
> synchronized (c) {
> while (!done) {
> try {
> c.wait();
> done = true;
> } catch (InterrupedException ie) {
> interrupted = true;
> }
> }
> }
> if (interrupted) {
> Thread.currentThread().interrupt();
> }
> }
>
> If that interrupt was unexpected, and causes a stack trace, then it would be nice if it could include the details from the thrown exception.
>
> Is there a better way to do the above?

To take a pattern from Spring Binding (which may have taken it from
elsewhere), you can keep a list of the caught exceptions, and then at
the end of your method if that list is not empty, throw a new exception
which contains the list.

BTW, the stack-trace will only be on the c.wait() line, since that is
where the interrupted exception will be thrown. This does not help you
know who interrupted you unexpectedly.

Do you really have a use-case for uninterruptableWait? Perhaps you
should instead have a different approach to interrupting that thread.
An interrupt is often a result of a user-action, and ignoring it will
make users mad. It may also be the case that the interrupt was caused
because something else failed, and waiting no longer is useful.

I'd be curious to read your use case. I've written similar code in the
past, and have since realized it was misguided.

Well, the idea is to be able to have a method where the caller doesn't
have to worry about handling interrupts.
> If you really need the details of the exception but can't throw from
> your local use site, I'd say wrapping the exception in a
> RuntimeExcpetion and throwing that is best. (Exception don't ever
> throwing RuntimeException; subclass it and throw your specific exception.)

On 9/25/2012 12:28 PM, Ivan Ryan wrote:
> On Sep 25, 4:33 pm, markspace <-@.> wrote:
>> On 9/25/2012 3:25 AM, wrote:
>>
>>> Is there a recommended way of "chaining" interrupted exceptions?
>>
>> I mostly agree with Eric. You shouldn't suppress interrupts unless you
>> must.
>
> Well, the idea is to be able to have a method where the caller doesn't
> have to worry about handling interrupts.

Fine: The called method handles its own interrupts, and
that's that. But then, the O.P. wants the information about
the interrupt to propagate back to the caller -- the very same
caller that "doesn't have to worry about handling interrupts!"

This looks 100% bogus to me. First, the JVM will insert spin-locks
where needed in your code automatically. No need to try to build your
own. The first rule of programming is "Don't re-invent the wheel."
(The 0th rule is "Get a deposit with all contracts.")

Second this is exactly the sort of situation where hiding an
InterrruptedException will get you into trouble. Better to just
re-throw and let the calling code deal with the exception (if desired).

But even better to just delete this class and use
java.util.concurrent.locks.ReetrantLock or something similar from the
Java API.

Plus, existing locks are more efficient that you might guess. I don't
think an AtomicBoolean is going to beat them. Look into
AbstractQueuedSynchronizer or LockSupport if you really must implement
your own subclass of Lock.

Daniel Pitts schrieb:
> Do you really have a use-case for uninterruptableWait? Perhaps you
> should instead have a different approach to interrupting that thread. An
> interrupt is often a result of a user-action, and ignoring it will make
> users mad. It may also be the case that the interrupt was caused
> because something else failed, and waiting no longer is useful.

Since he calls Thread.currentThread().interrupt() the next
wait() will throw an InterruptedException. So it is not
really ignored. It will be only ignored if all of the code
uses uninterruptableWait(), and nowhere Thread.interrupted()
is queried.

wrote:
> Is there a better way to do the above?

But the biggest flaw I see in the original code, is that
done=true is not called in the exception handler, so it will
not break out of the code. Actually it will inflict a new
InterruptedException by the wait() and so on.

(Erics and marks code have a similar flaw, the flaw there
is that wait() is again called, so code could block)

Probably the code is only working, since wait()s are allowed
to be spurious. But if this is not happening the CPU will
burn, burn, burn, ...

Anyway the code that will notify c should also set some state.
If it doesn't we cannot distinguish between a spurious wait (*) and
a wait by a notify. So code must use a loop, and to not confuse
the done flag and loop breaking, we can just shift the try/catch
outside of the loop, and even outside of the synchronized to
minimize the monitor region:

public boolean done; /* should be set by the thread that
notifies the lock */
public Object lock = new Object();

I prefer using notifyAll() from the beginning, since the condition
that is signaled can get more and more complex over the time, and
it might be that some threads will or will not react to it, so that
notify() might pick one which will not react, and then the signal
is spurious.

On 9/25/2012 1:47 PM, Jan Burse wrote:
> Hi,
>
> Anyway the code that will notify c should also set some state.
> If it doesn't we cannot distinguish between a spurious wait (*) and
> a wait by a notify. So code must use a loop, and to not confuse
> the done flag and loop breaking, we can just shift the try/catch
> outside of the loop, and even outside of the synchronized to
> minimize the monitor region:
>
> public boolean done; /* should be set by the thread that
> notifies the lock */

While I agree this works in some cases, I don't think it works for the
OP. He's trying to simulate a spin lock, by extending the Lock
interface. "done" is signaled by calling unlock() on that interface.

Of course you can turn a "OneTimeLock" into a "ManyTimeLock",
for example. You can reset the done inside the synchronized
of the waitDone(). The synchronized will assure that when
you leave the synchronized the done=false holds, since no
other thread will interfer while inside the synchronized
and after the wait():

So since there are not yet lambdas, we have to
write the method names of the interfaces. But
JDK 8 lambdas would exactly do this for us,
fill in the blanks. Sadly I don't currently
find the blog by John Rose that explains it.

Truly! And it only took you eight replies, mostly to your own posts, to
arrive at that idea. I think I mentioned ReetrantLock up thread? And
you should look at the source of that class, it's very interesting.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!