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
