yes, that is a good article. it is actually the one we used to decide about the
current way of handling InterruptedException. in retrospect it turns out to be
a nice way to document that a call is blocking.
From: thomas.john...@sun.com [mailto:thomas.john...@sun.com]
Sent: Friday, January 09, 2009 7:56 AM
Subject: Re: InterruptedException
Kevin Burton wrote:
> 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.
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.
> 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.