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)
From: "Uwe Schindler" <uwe@thetaphi.de>
To: <java-dev@lucene.apache.org>
References: <9ac0c6aa0910280453y1c35c80dr204713f202bde244@mail.gmail.com>
 <EF315EA4C9BA4C0491C7ADE49716DEA3@VEGA>
 <9ac0c6aa0910280547l2d929ae9k376ccba121c299d3@mail.gmail.com>
Subject: RE: Thread.interrupt()
Date: Wed, 28 Oct 2009 13:55:18 +0100
Message-ID: <710E38F80B7346288A6A52AE302A684C@VEGA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <9ac0c6aa0910280547l2d929ae9k376ccba121c299d3@mail.gmail.com>
Thread-Index: AcpXzPgMQDzS1/ilQBKWBJ+hmKKCjQAAJ+KQ

In this case (unchecked ex), we could have done that in 2.9, too :-)

I would prefer IOException so normal handlers would catch it and stop
indexing with a standard IO error (it is in fact an IOError, because
IndexWriter is not able to complete the merge). If somebody ignores a
IOException, it's his fault and his code will not work correctly.

-----
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 1:48 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Thread.interrupt()
>=20
> OK, I agree we shouldn't burden people with another checked exception.
>=20
> But we should differentiate it, so our own exception, subclassing
> either RuntimeException or IOException sounds good.
>=20
> 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?
>=20
> Mike
>=20
> 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
> subclass
> > 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,
> we
> > 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
> >
> >
>=20
> ---------------------------------------------------------------------
> 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