Kevin Burton wrote:
for the idiom associated with thread interrupt methods and
InterruptedException. I will hasten to add that the appropriate use of
this idiom in various libraries (including in JDK libraries) is
inconsistent at best and the behavior is in some cases OS dependent. So
being careful about the use (maybe even stearing clear) of interrupt for
'cancelable' operations is probably wise.
On Thu, Jan 8, 2009 at 3:21 PM, Benjamin Reed <br...@yahoo-inc.com> wrote:
InterruptedException is rather tricky because the semantics of
Thread.isInterrupted() is rather vague. specifically, it is unclear why
someone would interrupt a thread. usually Thread.interrupt() is used to shut
things down which requires special handing. thus we propagate it. for
example, i'm not clear how you shutdown your poll() method. an easy way to
do it would be to use Thread.interrupt().
so if you just don't have it throw InterruptedException then
thread.interrupt can't be used. It's an API decision really... if you don't
want people to interrupt then we don't have to throw InterruptedException.
I don't know many applications that use this in practice... does anyone on
this list? I always felt interrupt() was vestigial... notify/wait are
somewhat in the same category IMO but at least they are useful.
In my poll method I don't shutdown.... the goal was to have the developer do
everything in an event API and code that way.
Doing things in both sync and async operations is confusing.