Sorry to barge in, several things here:
I love the JDK. At the very least, you could say, that
'IllegalStateException' is the appropriate name in this case, as it
purveys the fact, that the results might fail to fulfill the contract.
UncheckedIoException doesn't do that. Pretty subtle! ;-) I would
expect, that the IOException would be nested as cause.
In the greater scheme of things, the 'unexpected' has its ways to mess
up things. RuntimeExceptions are Java's way of accepting, that the
unexpected actually exists. That is, why I would actually advocate, to
move away from the 'UncheckedIoException' in this case, and instead use
the IllegalStateException - and of course, nest the cause.
The missingFilesFirst/Last() methods are a good idea, only, that I
wouldn't start with 'missingFiles', but rather something like
'inaccessibleFiles' - because, appart from not being there, various
other reasons could lead to an exception - missing permissions, or
IO-errors to name two.
Catching this, you now have the problem, that you are depriving the user
of choice, because he actually might _want_ the Comparator to fail, if
the read fails.
So you might have have several mutually exclusive "access failure
policies" here:
inaccessibleFilesFirst/Last()
failIfInaccessible() -- using a fixed exception, I would suggest
IllegalStateException, as argued above.
But you could also do
failIfInaccessible(Function<Throwable, RuntimeException> exceptionFactory)
which would allow the user to inject his own favorite wrapper exception.
But we are still not in the clear, because the class and its use in a
sort has the potential to mess up things even without throwing any
exception. As unlikely as it sounds, if some process in the background
is constantly touching the sorted files, the sort could produce an
ordering, that never existed on the disk - I'm not quite certain, what
will happen, when during sorting a file time stamp will get read a
second time with a changed value. Incomplete sorting? Maybe an infinite
loop?
You could prevent this, by caching the result of the lastModified
timestamp for the duration of the sort - but then the documentation has
to make absolutely clear, that the comparator is no longer light-weight
constant, and should be discarded after the sort.
This could also used as an opportunity to safeguard against the
situation: by throwing another exception, if such a change was detected.
Having choice, you still have the possibility to reuse code, without
giving up control, and inadvertently hiding problems.
Just my thoughts.
Thomas
On 2023/12/03 12:29:40 Elliotte Rusty Harold wrote:
> On Sat, Dec 2, 2023 at 12:01 AM Miguel Muñoz <sw...@gmail.com> wrote:
> >
> > @Elliotte Rusty Harold,
> > I'd like to make two unrelated points.
> > 1. I wasn't suggesting the missingFilesFirst() or
missingFilesLast() methods as a solution to the issues raised in IO-813
LastModifiedFileComparator should not throw exceptions, period. I just
thought these methods would be useful for cases where the users needs to
sort file collections where some files might not be valid anymore. This
could easily arise in cases that are unrelated to the issue in IO-813.
>
> Yes, I agree. I suspect this can also happen in a case where a file
> never existed. Java Path and File objects do not guarantee the
> existence of the file pointed to. It's just a name that might or might
> not correspond to a file. I do suspect that missingFilesFirst() or
> missingFilesLast() are overkill. We should pick one behavior and make
> it always work that way.
>
> > 2. As for your point about external conditions changing the code, I
would like to point out that working with a file system is hardly the
only place where developers will encounter this problem.
>
> Absolutely. Every case where this can happen is another place where a
> checked exception is needed. I/O is the most common example, but there
> are others.
>
> That said, threads are *not* such a case because they are completely
> internal to the program. Concurrency failures within a program are
> bugs that can and should be fixed by the devs who maintain that
> program. Having fixed such a bug, the exception should not be able to
> occur. Bug free concurrent programming is hard. Personally I'm bad at
> it. But it is possible. I/O error free programming in programs that
> access the file system is not possible.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
Cheers, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
