Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Interrupted exception chaining

Reply
Thread Tools

Interrupted exception chaining

 
 
Daniele Futtorovic
Guest
Posts: n/a
 
      09-25-2012
On 25/09/2012 12:25, http://www.velocityreviews.com/forums/(E-Mail Removed) allegedly 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?


a) When catching an InterruptedException, always, always call
Thread.currentThread().interrupt() in the catch block. Always. Unless
you know what you're doing.

b) If you want a stacktrace, just print a stacktrace. Like, in the catch
block. But note that by definition, interruptedness is a state, not an
action. The only thing a stacktrace will tell you is where in the code
that state was /checked/, not where it was /set/.

--
DF.
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      09-26-2012
On 9/25/2012 4:26 PM, Jan Burse wrote:
> Hi,
>
> 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.


"The next wait()" is a re-execution of the first wait().
It is re-called *before* Thread.currentThread().interrupt(),
and will therefore *not* throw an InterruptedException until
and unless some other thread calls interrupt().

> 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.


Ah! So your diagnosis above is not about the O.P.'s code
at all, but about an undisclosed modification you have imagined.
Fine: Feel free to debug your own imagination. (Start with the
"will inflict" part, because AFAICS no such thing will happen.)

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


Both markspace and I pointed out that the O.P.'s code is
fundamentally flawed. My rewrite solved the question as asked,
while preserving the original flaw; markspace's addressed it
in a slightly different way, still preserving the flaw. I think
it hardly fair to blame me and markspace for the flaw we both
carefully preserved (and pointed out).

> 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, ...


This the first time I have encountered "spurious" in the
description of a *call* to wait(). It is known that a *return*
from wait() may be "spurious" in the sense that it can occur
without a notify() or notifyAll() or interrupt(), but in what
sense can the *call* be "spurious?"

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Jan Burse
Guest
Posts: n/a
 
      09-26-2012
Daniele Futtorovic schrieb:
> a) When catching an InterruptedException, always, always call
> Thread.currentThread().interrupt() in the catch block. Always. Unless
> you know what you're doing.


No

 
Reply With Quote
 
Jan Burse
Guest
Posts: n/a
 
      09-26-2012
Jan Burse schrieb:
>> a) When catching an InterruptedException, always, always call
>> Thread.currentThread().interrupt() in the catch block. Always. Unless
>> you know what you're doing.

>
> No


Mh, yes. Catch it at the right moment, outside your loop.
And yes Thread.currentThread().interrupt() isn't the worst.

And don't forget all your I/O can also be interrupted, so
you have to watch as well the following exception:

InterruptedIOException
http://docs.oracle.com/javase/1.4.2/...Exception.html

But it usually goes unrecognized or ripples down, since
it is a subclass of IOException. Also the bytesTransferred
doesn't work well, especially if the stream is wrapped.

Bye
 
Reply With Quote
 
Daniele Futtorovic
Guest
Posts: n/a
 
      09-26-2012
On 26/09/2012 10:32, Jan Burse allegedly wrote:
> Jan Burse schrieb:
>>> a) When catching an InterruptedException, always, always call
>>> Thread.currentThread().interrupt() in the catch block. Always. Unless
>>> you know what you're doing.

>>
>> No

>
> Mh, yes. Catch it at the right moment, outside your loop.
> And yes Thread.currentThread().interrupt() isn't the worst.
>
> And don't forget all your I/O can also be interrupted, so
> you have to watch as well the following exception:
>
> InterruptedIOException
> http://docs.oracle.com/javase/1.4.2/...Exception.html
>
>
> But it usually goes unrecognized or ripples down, since
> it is a subclass of IOException. Also the bytesTransferred
> doesn't work well, especially if the stream is wrapped.


The point, which I believe you're missing, is that when you catch the
InterruptedException, the thread's interrupted status is _cleared_.
Normally, you don't want to lose that information (to wit, that it's
been interrupted). Unless, again, you specifically know what you're
doing. But since in my experience the overwhelming majority of
developers, even the experienced ones, are unaware of this fact, I
reckon it warrants a little vehemence.

--
DF.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: backporting PEP 3134 "Exception Chaining and Embedded Tracebacks"to Python 2.7 Demian Brecht Python 0 02-19-2013 08:56 PM
backporting PEP 3134 "Exception Chaining and Embedded Tracebacks" toPython 2.7 Piotr Dobrogost Python 0 02-19-2013 08:54 PM
Does Ruby support exception wrapping (exception chaining)? Hartin, Brian Ruby 15 02-23-2011 07:02 AM
"Interrupted function call" exception while relogging :( Sylwia Python 2 01-08-2004 03:32 PM
"Interrupted function call" exception in Python service while relogging Nazgul Python 0 01-08-2004 09:43 AM



Advertisments