Shouldn't this code have thrown a FileSystemLoopException instead?

[Alan Bateman]

On 05/02/2015 15:50, Francis Galiegue wrote:
> Test dir setup:
>
> ln -s l2 l1
> ln -s l1 l2
>
> Java code:
>
> final Random random = new Random();
> final byte[] content = new byte[1024];
> random.nextBytes(content);
>
> final Path loop = baseDir.resolve("l1");
>
> try (
>      final OutputStream out = Files.newOutputStream(loop);
> ) {
>      out.write(content);
> } catch (FileSystemException e) {
>      System.out.println(e.getClass().getSimpleName());
> } catch (IOException wtf) {
>      System.out.println("Meh, I didn't expect that...");
>      wtf.printStackTrace(System.out);
> }
>
> Prints out:
>
> FileSystemException
>
> even though FileSystemLoopException is defined?
>
> (note: Ubuntu Linux x86_64 14.10, "official" Oracle JDK 1.8u25)

I would expect the exception message to contain something like "Too many 
levels of symbolic links" as that is the error that the kernel should 
report for this case. I see your code just prints the exception name so 
you might not see the detail.

As I think I've mentioned here before, we've deliberately avoided trying 
to overly specify the exceptions and instead limit it to cases where it 
would be reasonable to recover in a specific scenario. So while we could 
consistently map ELOOP to FileSystemLoopException then it's not clear 
that an application could take recovering action that is different to 
that of catching the more general IOException. Also the main purpose of 
FileSystemLoopException in the API is Files.walk and walkFileTree where 
it is important to detect and report cycles when following links. So I'm 
not saying that we shouldn't do this, it's just not clear that an 
application or library would do anything useful with it.

-Alan