NIO question: Path.toFile()

[Bernd]

Hello,

I think if you do not think in terms of "is it the default provider" but in
"does it allow to convert to file" the exception is better understood (and
more generically usefull). However for a specified API feedback its rather
strange (and I would agree with IllegalState, since the state in this case
is which provider was associated with it).

Greetings
Bernd
Am 27.11.2014 10:06 schrieb "Alan Bateman" <Alan.Bateman at oracle.com>:

> On 26/11/2014 22:35, Jonathan Gibbons wrote:
>
>> NIO folk,
>>
>> java.nio.file.Path.toFile() is specified to throw
>> UnsupportedOperationException if this Path is not associated with the
>> default provider.
>>
>> UOE seems a somewhat strange choice here. IllegalStateException or a
>> custom exception might be seen as more obvious alternatives. (It's also
>> somewhat weird that UOE is explicitly documented as being a member of the
>> Java Collections Framework.)
>>
>> So, if there any background rationale of why UOE was chosen here? I'm not
>> looking to change the spec for Path.toFile() in any way, but I am looking
>> to design a higher level API that may encounter the same underlying
>> problem, that a Path may not be associated with the default provider.   At
>> my higher level, I need to decide whether to go with UOE, just because that
>> is what Path.toFile() does, or whether to convert it into some other
>> exception.
>>
>
> I think UOE is right because it must fail for every instance of an
> implementation type that is not associated with the default provider. I
> don't think IllegalStateException would have worked there aren't any states
> where this method could succeed.
>
> A blog that I've re-read a few things is Kevin Bourrillion's take on
> unchecked exceptions:
> http://smallwig.blogspot.co.uk/2008/06/common-java-
> unchecked-exception-types.html
>
> It's probably an area where more guidelines need to be written down, also
> probably a topic where it's impossible to get broad agreement.
>
> -Alan.
>
>
>