Allow `MoreFiles.fileTraverser()` to have customizable error handling

Context

I’ve noticed that when using Kotlin’s File.walk function, if it doesn’t have permission to read a subdirectory, it will just skip over that subdirectory by default.

If one wanted to handle that case as an error, they’d use FileTreeWalk.onFail. For example,

aDirectory.walk().onFail { fileOrSubdirectory, ex -> println(ex.message) }

(This is the same behaviour as Java’s Files.walkFileTree, where one implements FileVisitor::visitFileFailed to also handle any unreadable files/directories.)

By comparison, Java’s Files.walk stream and Guava’s MoreFiles.fileTraverser() let the unreadable directory bubble up as an IOException. This means that if either of these APIs can’t read a file/directory, they stop there and then, rather than reading on.

I think this behaviour makes these two APIs impractical sometimes. In fact, there seems to be evidence for this, with a StackOverflow question and a now-closed Java bug report on Java’s Files.walk.

Feature request

Consider giving MoreFiles.fileTraverser() a customizable, more lenient error-handling mechanism than just bubbling up the first IOException that occurs.

For example, Guava could introduce something like Kotlin’s FileTreeWalk.onFail, which would allow code like,

Path directory = ...;
Iterable<Path> filesAndDirectories =
    MoreFiles.fileTraverser()
        .onFail((file, ex) -> System.err.println(ex.getMessage()))
        .breadthFirst(directory);
for (var path : filesAndDirectories) {
  println(path)
}

This would forward any IOExceptions to onFail, rather than throwing them, and resume traversing afterwards.

Note: Implementation-wise, this probably means that MoreFiles.fileTraverser() would need to return a new sub-type of Traverser that has an onFail method, or a new type altogether.

[PrachiPrakash]

@jbduncan that okay I guess was just looking around the code found this interesting so tried to give it a shot. not aware that this was still under discussion.

[jbduncan]

@ManishOffi Ah, sorry, I can’t, as I’m not a member of the Guava team or even a Googler. Furthermore it looks like the API still hasn’t been decided upon, so there wouldn’t be anything to code anyway.