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