Good question. Since the missingFilesFirst/Last() methods would most likely be
used for sorting, I'm going to assume your "ls -type" command sorts the
files at
some point. I'll assume it's by last-modified, to put more recent files first.
Without calling the missingFilesFirst() method, the ls utility's call to sort
the results
would throw an IOException when it encountered a file that had been deleted.
And
since the exception would be encountered while sorting, it's complicated to
recover
from the exception. (I suppose the utility could repeatedly re-sort until it
stopped
getting exceptions.)
With the new method, the results come back with the missing files first, which
is
consistent with last-modified, since they were recently deleted. The utility
could
now either present them as deleted, or remove them from the output completely.
-- Miguel
P.S. I've decided they shouldn't go in AbstractFileComparator, because that
class
isn't public, so users wouldn't be able to see the JavaDocs. That means they
should probably go in FileUtils, unless somebody has a better idea.
-- MM
On Dec 1 2023, at 2:56 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> 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
> >
>
