rename return values

[Bryan Duxbury <br...@rapleaf.com>]

Hey all,

Why is it that FileSystem.rename returns true or false instead of  
throwing an exception? It seems incredibly inconvenient to get a  
false result and then have to go poring over the namenode logs  
looking for the actual error message. I had this case recently where  
I'd forgotten to create the parent directories, but I had no idea it  
was failing since there were no exceptions.

-Bryan

Re: rename return values

[Arun C Murthy <ac...@yahoo-inc.com>]

On Sep 30, 2008, at 1:37 PM, Bryan Duxbury wrote:

> Hey all,
>
> Why is it that FileSystem.rename returns true or false instead of  
> throwing an exception? It seems incredibly inconvenient to get a  
> false result and then have to go poring over the namenode logs  
> looking for the actual error message. I had this case recently where  
> I'd forgotten to create the parent directories, but I had no idea it  
> was failing since there were no exceptions.
>

Speculating...

To be consistent to with java.io.File.renameTo?(http://java.sun.com/javase/6/docs/api/java/io/File.html#renameTo(java.io.File) 
)

Arun

Re: rename return values

[Chris Douglas <ch...@yahoo-inc.com>]

It's not ignored; it returns failure. Further, the point wasn't that  
the File API is good, but rather that the File API doesn't provide a  
cause for FileSystem to convert into a descriptive exception if the  
error originates from there (as it does in many FileSystem  
implementations). Finally, unlike File, the FileSystem API *permits*  
rename to throw IOExceptions (IIRC, it's possible to get quota and  
permission exceptions from rename in HDFS), but not all failures  
result in exceptions; application code that relies on a set of  
exceptions from a particular FileSystem assumes more than the  
interface claims.

Ignoring the return value from rename causes silent failures. I'm  
sympathetic to the debugging burden, but if you were debugging this  
with LocalFileSystem, an exception would be no more descriptive than  
checking the return value. All that said, you can certainly emulate  
your preferred behavior with a FilterFileSystem that throws instead of  
returning false. -C

On Sep 30, 2008, at 4:47 PM, Bryan Duxbury wrote:

> It's very interesting that the Java File API doesn't return  
> exceptions, but that doesn't mean it's a good interface. The fact  
> that there IS further exceptional information somewhere in the  
> system but that it is currently ignored is sort of troubling.  
> Perhaps, at least, we could add an overload that WILL throw an  
> exception if there is one to report.
>
> -Bryan
>
> On Sep 30, 2008, at 1:53 PM, Chris Douglas wrote:
>
>> FileSystem::rename doesn't always have the cause, per  
>> java.io.File::renameTo:
>>
>> http://java.sun.com/javase/6/docs/api/java/io/File.html#renameTo(java.io.File)
>>
>> Even if it did, it's not clear to FileSystem that the failure to  
>> rename is fatal/exceptional to the application. -C
>>
>> On Sep 30, 2008, at 1:37 PM, Bryan Duxbury wrote:
>>
>>> Hey all,
>>>
>>> Why is it that FileSystem.rename returns true or false instead of  
>>> throwing an exception? It seems incredibly inconvenient to get a  
>>> false result and then have to go poring over the namenode logs  
>>> looking for the actual error message. I had this case recently  
>>> where I'd forgotten to create the parent directories, but I had no  
>>> idea it was failing since there were no exceptions.
>>>
>>> -Bryan
>>
>

Re: rename return values

[Bryan Duxbury <br...@rapleaf.com>]

It's very interesting that the Java File API doesn't return  
exceptions, but that doesn't mean it's a good interface. The fact  
that there IS further exceptional information somewhere in the system  
but that it is currently ignored is sort of troubling. Perhaps, at  
least, we could add an overload that WILL throw an exception if there  
is one to report.

-Bryan

On Sep 30, 2008, at 1:53 PM, Chris Douglas wrote:

> FileSystem::rename doesn't always have the cause, per  
> java.io.File::renameTo:
>
> http://java.sun.com/javase/6/docs/api/java/io/File.html#renameTo 
> (java.io.File)
>
> Even if it did, it's not clear to FileSystem that the failure to  
> rename is fatal/exceptional to the application. -C
>
> On Sep 30, 2008, at 1:37 PM, Bryan Duxbury wrote:
>
>> Hey all,
>>
>> Why is it that FileSystem.rename returns true or false instead of  
>> throwing an exception? It seems incredibly inconvenient to get a  
>> false result and then have to go poring over the namenode logs  
>> looking for the actual error message. I had this case recently  
>> where I'd forgotten to create the parent directories, but I had no  
>> idea it was failing since there were no exceptions.
>>
>> -Bryan
>

Re: rename return values

[Chris Douglas <ch...@yahoo-inc.com>]

FileSystem::rename doesn't always have the cause, per  
java.io.File::renameTo:

http://java.sun.com/javase/6/docs/api/java/io/File.html#renameTo(java.io.File)

Even if it did, it's not clear to FileSystem that the failure to  
rename is fatal/exceptional to the application. -C

On Sep 30, 2008, at 1:37 PM, Bryan Duxbury wrote:

> Hey all,
>
> Why is it that FileSystem.rename returns true or false instead of  
> throwing an exception? It seems incredibly inconvenient to get a  
> false result and then have to go poring over the namenode logs  
> looking for the actual error message. I had this case recently where  
> I'd forgotten to create the parent directories, but I had no idea it  
> was failing since there were no exceptions.
>
> -Bryan