Path.checkAccess (6873681)

[fm]

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.

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
>