<Swing Dev> [9] Review Request for 8081722: Provide public API for file hierarchy provided by sun.awt.shell.ShellFolder

[Sergey Bylokhov]

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.