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
>
>
