NIO question: Path.toFile()

Alan Bateman Alan.Bateman at oracle.com
Thu Nov 27 08:05:53 UTC 2014


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.





More information about the core-libs-dev mailing list