Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: Best way to purposely corrupt an index?
Content-Transfer-Encoding: quoted-printable
Date: Wed, 20 Apr 2005 08:52:07 -0400
Message-ID: <6C1FF371E2319F45BABA49F9BA1BD039036F3F@mail.lou.emergint.com>
Thread-Topic: Best way to purposely corrupt an index?
Thread-Index: AcVFhJFtZ8W4wb/ERQaMSPR13Eg17wAIKYpw
From: "Kevin L. Cobb" <cobbk@emergint.com>
To: <java-user@lucene.apache.org>

My policy on this type of exception handling is to only byte off what
you can chew. If you catch an IOException, then you simply report to the
user that an unexpected error has occurred and the search engine is
unobtainable at the moment. Errors should be logged and developers
should look at the specifics of the error to solve the issue. As you
implied, either it's a corrupted index, a permission problem, or another
access problem.=20

Trying to attack the issue much deeper than this will sacrifice
development/maintenance time for very little payback in the end if you
expect this error to occur infrequently.=20


-----Original Message-----
From: Andy Roberts [mailto:mail@andy-roberts.net]=20
Sent: Wednesday, April 20, 2005 5:43 AM
To: java-user@lucene.apache.org
Subject: Re: Best way to purposely corrupt an index?

On Wednesday 20 Apr 2005 08:27, Maik Schreiber wrote:
> > As the index is rather critical to my program, I just wanted to make
it
> > really robust, and able to cope should a problem occur with the
index
> > itself. Otherwise, the user will be left with a non-functioning
program
> > with no explanation. That's my reasoning anyway.
>
> You should perhaps go about implementing an automatic index backup
feature
> of some sort. In the case of index corruption you would at least be
able to
> go back to the latest backup.

Don't worry, I know what I intend to do *should* an error exist. My
original=20
post was about how to detect corrupt indexes, and also how to purposely=20
corrupt an index for the purposes of testing.

Note, IndexReader throws IOExceptions, but, this could be for a
multitude of=20
reasons, not just a corrupt index. I was rather hoping for a=20
CorruptIndexException of some sort!

It looks to me that if I do get an IOException, I will then have to
perform a=20
number of additional checks to eliminate the other possible causes of=20
IOExceptions (such as permissions issues), and by a process of
elimination,=20
determine a corrupt index.

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


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