Ok, opened LUCENE-2316 to track this.
Shai
On Sat, Mar 13, 2010 at 3:49 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> I like the proposed new semantics (throw FNFE if the file does not
> exist), and the migration path (new method, deprecate old).
>
> Mike
>
> On Sat, Mar 13, 2010 at 7:46 AM, Shai Erera <ser...@gmail.com> wrote:
> > I think it falls under the semantics of dir.fileLength() and not the
> > semantics of the implementation right? Unfortunately, the semantics of
> > Directory.fileLength() are not specified, which made it easy for
> extensions
> > to invent their own.
> >
> > I myself am not sure what's better - return 0 as the length for a file
> that
> > does not exist, or throw FNFE to alert the caller that he's querying a
> file
> > that does not exist. FSDirectory got away with it by using File API which
> > just happens to return 0 for a non-existing file. RAMDirectory chose to
> > alert the caller. My feeling is that these two were written by two
> different
> > persons, or separate times, each understanding the method differently.
> >
> > I think we should make the semantics clear, and declare a better
> contract,
> > by documentation and possible also by method signature. If for example we
> > decide that it should return 0 for non-existing files, then I think we
> can
> > remove the IOException from the method sig? But maybe we want to allow
> > IOException to be thrown by Directories that could actually fail on
> probing
> > the file length.
> >
> > I would propose to declare the semantics of fileLength like this:
> > * Returns the length of the file denoted by <code>name</code> if the file
> > exists. The return value may be anywhere between 0 and Long.MAX_VALUE.
> > * Throws FileNotFoundException if the file does not exist. Note that you
> can
> > call dir.fileExists(name) if you are not sure whether the file exists or
> > not.
> >
> > That way it's clear. We can then change IW code to call fileExists if it
> > expects to fail on either of the two.
> >
> > Question is - how do we do this w/o breaking Directory implementations
> out
> > there? I think that we might be safe with it, if we make sure all of IW
> code
> > queries fileExists before. However if someone relies on FSDir to return 0
> > instead of throwing exception, that will break his app.
> >
> > Backwards is always tricky. This does not result in compilation error,
> but a
> > runtime change. We might be able to get away with it if we think users
> run
> > some tests before they deploy a new Lucene .jar ... but otherwise, we
> should
> > create a new method, w/ clear semantics? Something like:
> >
> > /**
> > * @deprecated the method will become abstract when #fileLength(name) has
> > been removed.
> > */
> > public long getFileLength(String name) throws IOException {
> > long len = fileLength(name);
> > if (len == 0 && !fileExists(name)) {
> > throw new FileNotFoundException(name);
> > }
> > return len;
> > }
> >
> > The first line just calls the current impl. If it throws exception for a
> > non-existing file, we're ok. The second line verifies whether a 0 length
> is
> > for an existing file or not and throws an exception appropriately.
> >
> > That is of course only if everybody else agree w/ these semantics.
> >
> > Shai
> >
> > On Sat, Mar 13, 2010 at 1:21 PM, Marcelo Ochoa <marcelo.oc...@gmail.com>
> > wrote:
> >>
> >> Uwe:
> >> > That is not true, the API says:
> >> > "Creates a new File *instance* from a parent pathname string and a
> child
> >> > pathname string."
> >> >
> >> > Please note "instance", so it will never create the file on disk. New
> >> > File() just creates a file instance but no file on disk. You can check
> this
> >> > with a simple test.
> >> OK but what the about the exception?
> >> If the creation of the File instance do not throw an exception and
> >> the method File.length() returns 0 if a file does not exists
> >> RAMDirectory and other classes which also override this method should
> >> be modified to return 0.
> >> Best regards, Marcelo.
> >>
> >> --
> >> Marcelo F. Ochoa
> >> http://marceloochoa.blogspot.com/
> >> http://mochoa.sites.exa.unicen.edu.ar/
> >> ______________
> >> Want to integrate Lucene and Oracle?
> >>
> >>
> http://marceloochoa.blogspot.com/2007/09/running-lucene-inside-your-oracle-jvm.html
> >> Is Oracle 11g REST ready?
> >> http://marceloochoa.blogspot.com/2008/02/is-oracle-11g-rest-ready.html
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: java-dev-h...@lucene.apache.org
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>
>
