NIO question: Path.toFile()
jonathan.gibbons at oracle.com
Thu Nov 27 16:32:48 UTC 2014
On 11/27/2014 12:05 AM, Alan Bateman wrote:
> 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:
> 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.
Thanks for the perspective on why it is UOE. Kevin's blog is
interesting, but as I read it, it argues against UOE :-) Given a
collection of Path objects, generated from various file systems, some
may return a value from Path.toFile(), and some may throw an exception,
depending on whether something like the following condition is true or not
path.getFileSystem() == FileSystems.getDefault()
(Of course, that expression itself is scary, since the javadoc for
FileSystems.getDefault() says it may throw "an unspecified error".)
I think this means that from the point of view of an API using
java.nio.file.Path internally, UOE should not be propagated to clients
of that API. Instead, it should be caught and rethrown as something more
specific to that level of API.
More information about the core-libs-dev