Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <EF315EA4C9BA4C0491C7ADE49716DEA3@VEGA>
References: <9ac0c6aa0910280453y1c35c80dr204713f202bde244@mail.gmail.com>
	 <EF315EA4C9BA4C0491C7ADE49716DEA3@VEGA>
Date: Wed, 28 Oct 2009 08:47:51 -0400
Message-ID: <9ac0c6aa0910280547l2d929ae9k376ccba121c299d3@mail.gmail.com>
Subject: Re: Thread.interrupt()
From: Michael McCandless <lucene@mikemccandless.com>
To: java-dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

OK, I agree we shouldn't burden people with another checked exception.

But we should differentiate it, so our own exception, subclassing
either RuntimeException or IOException sounds good.

I think I'd prefer subclassing RuntimeException so that existing
handlers do not in fact suppress it.  If you are advanced enough to be
calling Thread.interrupt (or using Futures, which can call
Thread.interrupt), then you should be able to handle the resulting
unchecked exception?

Mike

On Wed, Oct 28, 2009 at 8:37 AM, Uwe Schindler <uwe@thetaphi.de> wrote:
> I have seen this yesterday, too (when coming around the assert
> Thread.holdsLock()), but I would not do that. How about defining a subcla=
ss
> of RuntimeException like InterruptedRuntimeException, so it does not need=
 to
> be declared, but one could still catch it.
>
> Normally an interrupt inside Lucene would normally break a lot, so it is =
not
> done alone with catching it in user code? InterruptedException is only
> useful if you want to really control coexistence of threads or break IO
> operations, but I would not recommend to interrupt any foreign thread not
> part of your code (like a merging thread). If this was done by someone, w=
e
> are fine with throwing a fatal error in the indexer. Maybe make it a
> subclass of IOException (because the indexing IO is interrupted)?
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>> -----Original Message-----
>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>> Sent: Wednesday, October 28, 2009 12:54 PM
>> To: java-dev@lucene.apache.org
>> Subject: Thread.interrupt()
>>
>> As a followon to LUCENE-1573, we had stated that in 3.0 instead of
>> throwing RuntimeException when a Thread inside Lucene is interrupted,
>> we would throw InterruptedException.
>>
>> Do we want to do this? =A0Technically I think it's the right thing to
>> do, but, I started to implement it and found that it basically results
>> in nearly every API now throwing InterruptedException (just like
>> IOException).
>>
>> Thoughts?
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org