> So the proper behaviour is to return false & IOE (on proper occasion)?

I don't object to it, as I think it's reasonable (as today we may be hiding
some info from the app). However, given that today we never throw IOE, and
that if we start doing so, we'll change runtime behavior, I lean towards
keeping the method simple and remove the throws declaration. Well, it's
either we change the impl to throw IOE, or remove the declaration
altogether.

Changing the impl to throw IOE "on proper occasion" might be problematic --
IndexNotFoundException is thrown when an empty index directory was given,
however by its Javadocs, it can also indicate the index is corrupted.
Perhaps the jdocs are wrong and it's thrown only if the index directory is
empty, or no segments files are found. If that's the case, then we should
change its javadocs. Otherwise, it will be difficult to know whether the
INFE indicates an empty directory, for which you'll want to return false, or
a corrupt index, for which you'll want to throw the exception.

Besides, I consider this method almost like File.exists() which doesn't
throw an exception. If indexExists() returns false, the app can decide to
investigate further by trying to open IndexReader or read the SegmentInfos.
But the API as-is needs to be simple IMO.

> Otherwise please keep the throws declaration so that you won't break
public APIs if this changes implementation.

Removing the throws declaration doesn't break apps. In the worse case,
they'll have a catch block which is redundant?

Shai

On Mon, Mar 21, 2011 at 4:12 PM, Sanne Grinovero
<[email protected]>wrote:

> 2011/3/21 Earwin Burrfoot <[email protected]>:
> > Technically, there's a big difference between "I checked, and there
> > was no index", and "I was unable to check the disk because file system
> > went BANG!".
> > So the proper behaviour is to return false & IOE (on proper occasion)?
>
> +1 to throw the exception when proper to do so
>
> Otherwise please keep the throws declaration so that you won't break
> public APIs if this changes implementation.
>
> >
> > On Mon, Mar 21, 2011 at 13:53, Michael McCandless
> > <[email protected]> wrote:
> >> On Mon, Mar 21, 2011 at 12:52 AM, Shai Erera <[email protected]> wrote:
> >>> Can we remove the declaration? The method never throws IOE, but instead
> >>> catches it and returns false. I think it's reasonable that such a
> method
> >>> will not throw exceptions.
> >>
> >> +1
> >>
> >> --
> >> Mike
> >>
> >> http://blog.mikemccandless.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]
> >> For additional commands, e-mail: [email protected]
> >>
> >>
> >
> >
> >
> > --
> > Kirill Zakharenko/Кирилл Захаренко
> > E-Mail/Jabber: [email protected]
> > Phone: +7 (495) 683-567-4
> > ICQ: 104465785
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to