On 21/01/16 09:16, Semyon Sadetsky wrote:
There are still inconsistency. The isFileSystem(), isParent(),
getSystemIcon, getSystemDisplayName() etc do not throw an exception in
case of null, but return some default value(null,true,false). Same for
FileNotFoundException() most of the methods just catch this exception
and return the default value.
The methods you've mentioned do not throw NPE but other methods in the
FSV class do throw NPE if called with null argument.
they raise NPE not an IAE. ok I am fine to use NPE.
Some other issue is inconsistency between isLink() vs getLinkLocation()
getLinkLocation() should "Returns {@code null} if the specified file is
not a shell interpreted link", but isLink() return false if
FileNotFoundException which means that getLinkLocation() should return null;
the next code can work incorrectly:
FileSystemView fsv = FileSystemView.getFileSystemView();
File file = "some unexisted file";
if (fsv.isLink(file)) {
if (fsv.getLinkLocation(file) == null) {
throw new RuntimeException();
}
} else {
if (fsv.getLinkLocation(file) != null) {
throw new RuntimeException();
}
}
There are some checks in the code related to "C:\pagefile.sys" and
"C:\Winnt\Profiles\joe\history\History.IE5" can you double check how the
new methods will work with these files.
Your point that there is inconsistency sounds a bit odd. If this
reasoning we can not add a new method which throws an exception to the
class not having methods throwing this exception. How methods of the FSV
class related to different aspects of the file system can be
inconsistent? They are simply not related to each other.
--
Best regards, Sergey.
