Hi Miguel, I like the idea but I think we need a use case, even if it's one we can only write about here, otherwise we are making everything more complicated.
For example, if implementing an "ls"-type, command, a UI, or an app configuration, what would be best for a user? Let's say some files disappear after I start the operation that needs file processing, then: Would I expect the use case to blow up and give me an error, or to silently succeed and tell me (or not tell me) somehow? I'd like to hear how these methods play into that (or not) and how (or not). Gary On Fri, Dec 1, 2023, 4:50 AM Miguel Muñoz <swingguy1...@gmail.com> wrote: > > > In my comments about issue IO-813 LastModifiedFileComparator should not > throw exceptions, period, I made a suggestion that I thought I'd repeat > here. I was thinking of adding these two methods to AbstractFileComparator. > > > > public static Comparator<File> > missingFilesFirst(Comparator<File> comparator) > > > public static Comparator<File> > missingFilesLast(Comparator<File> comparator) > > > These would work like Comparator.nullsFirst() and Comparator.nullsLast(). > They would allow users to work with collections of Files that might not > point to valid files, without having to worry about IOExceptions. > > > > I'm not sure if AbstractFileComparator is the best place to put it. It's > not a public class, but the methods would be available from any of the > subclasses. A better place might be in FileUtils, although that's in a > different package. > > > > What do you think? > > > > -- Miguel Muñoz >
