On Sat, Dec 2, 2023 at 12:01 AM Miguel Muñoz <swingguy1...@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
