Path.checkAccess (6873681)

[Rémi Forax]

Le 13/10/2010 20:07, fm a écrit :
> I think Alan is on to something here. I think good programming
> warrants checking a file for access (prior to doing so) if there is a
> "reasonable" chance that accessing the file may fail due to some
> permission issue. Of course, any code actually accessing a file will
> still need to catch (or declare to throw ) the various IOExceptions
> that may occur.
>
> On a related subject, it has been brought up a few times that
> convenience methods such as checkAccess(...) or exists() don't
> guarantee that access or existence to a file hasn't changed between
> the time of the check and the time that the file is actually accessed.
> I think this risk will be understood by programmers and does not
> invalidate the usefulness of these convenience methods. If I can
> handle an alternative case because I did a check first as opposed to
> reacting to it by catching the exception, then this can often be a
> good thing. The IOException hierarchy will always be there as a last
> resort (or safety net) to handling file access that goes wrong for
> some reason.
>    

Without checkAccess the code is simpler !
This is, in my opinion, a strong argument for not using checkAccess.
before by example opening a file.

Rémi

> On Wed, Oct 13, 2010 at 10:27 AM, Alan Bateman<Alan.Bateman at oracle.com>  wrote:
>    
>> Rémi Forax wrote:
>>      
>>> :
>>> The other solution is to move checkAccess in BasicFileAttributes or in
>>> Attributes.
>>> If you decide to move checkAccess, I think that isHidden should follow.
>>>        
>> The effective access relates to the file content rather than the attributes
>> so I don't think this would work too well. The isHidden is also not related
>> to the basic attributes (it's a function of the file name on Unix for
>> example).
>>
>> -Alan
>>
>>