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.
