[ 
https://issues.apache.org/jira/browse/IO-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791915#comment-17791915
 ] 

Miguel Munoz commented on IO-813:
---------------------------------

In my experiments, this class throws the expected UncheckedIOException if a 
file is missing. This means the class satisfies the condition that 
{{{}sgn(cmp.compare(a, b)) == -sgn(cmp.compare(b, a)){}}}, which my experiments 
have confirmed. So I don't see any problem with the current code. In general, a 
method should throw an exception if it receives bad data. It's up to the user 
to make sure the input is valid.

Elliotte Rusty Harold is certainly correct that file systems are unstable and 
occasionally throw spurious exceptions, but I don't think it's our job to fix 
that problem. If somebody yanks a memory stick out while my code is reading 
from it, it's not the exception that will annoy me. I think the class is fine 
as it is. 

However, if users want to work with File objects that may not point to real 
files, we could conceivably follow the example of {{Comparators.nullsFirst()}} 
and {{{}.nullsLast(){}}}, we could write 
{{missingFilesFirst(Comparator<File>)}} and a 
{{missingFilesLast(Comparator<File>)}} methods, and add them to 
AbstractFileFilter.

> LastModifiedFileComparator should not throw exceptions, period
> --------------------------------------------------------------
>
>                 Key: IO-813
>                 URL: https://issues.apache.org/jira/browse/IO-813
>             Project: Commons IO
>          Issue Type: Bug
>            Reporter: Elliotte Rusty Harold
>            Priority: Major
>
> LastModifiedFileComparator is likely broken by design since it can 
> unexpectedly throw UncheckedIOException. This violates the contract of 
> Comparable.compareTo which is not documented to throw that exception. 
> I analyzed almost this exact case in detail here: 
> https://medium.com/@elharo/when-you-cant-throw-an-exception-b9f9b0db9ba4
> I'm not sure how to fix this now, but I'm tempted to simply deprecate this 
> entire class.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to