lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Different behavior of Directory.fieldLength()
Date Sat, 13 Mar 2010 13:49:50 GMT
I like the proposed new semantics (throw FNFE if the file does not
exist), and the migration path (new method, deprecate old).


On Sat, Mar 13, 2010 at 7:46 AM, Shai Erera <> 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 <>
> 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
>> ______________
>> Want to integrate Lucene and Oracle?
>> Is Oracle 11g REST ready?
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message