On 11/27/2014 08:47 AM, Alan Bateman wrote:
On 27/11/2014 16:32, Jonathan Gibbons wrote:
Alan,
Thanks for the perspective on why it is UOE. Kevin's blog is
interesting, but as I read it, it argues against UOE :-)
I think there's a discussion point there as Path is an interface and
there are different concrete types. In any case, we can't change this
of course.
:
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.
The toFile() method is meant for interoperability with the legacy API
and so some care is required to avoid using it on Paths to objects in
arbitrary file system that could not be represented by java.io.File. I
think I'd need to see more context to know if you should be
propagating anything or whether the issue is just an incorrect
assumption somewhere.
-Alan
The context is that we are considering extending
javax.tools.StandardJavaFileManager to include support for
java.nio.file.Path as well as java.io.File. This file manager provides
implementations for JavaFileObject that can wrap java.io.File today, and
java.nio.file.Path (proposed.) An existing client will only use the
File-centric methods, and a well-written updated client should probably
only use the Path-centric methods, but in terms of complete API design,
we are left with the need to specify what happens if someone starts off
by using a method like void setLocation(Location, Iterable<Path>) and
then later on, for some reason, tries to use Iterable<File>
getLocation(Location). The "obvious" implementation would seem to be to
try and use .toFile() on each element of the sequence given to
setLocation. Which gets to the question of what to do with the UOE that
might occur.
Yes, the potential client of this proposed updated form of
StandardJavaFileManager may have made a mistake trying to mix and match
File-centric methods and Path-centric methods, but that doesn't absolve
us of the responsibility to try and "do something sensible" in this
case. My inclination is to try and use IllegalStateException, or maybe a
custom subtype thereof.
-- Jon
