[ https://issues.apache.org/jira/browse/IO-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771526#comment-17771526 ]
Gilles Sadowski commented on IO-814: ------------------------------------ bq. This was a behavior breaking change, [...] There is no denying that it is not nice to users who relied on the previous behaviour. bq. [...] an incorrect one to boot. Although it could/should have occurred in a new major version, it is not incorrect if one assumes that the API should switch to not using checked exceptions. bq. Operations that can have I/O errors should throw IOException if they can't directly handle the I/O error. As discussed previously, there is no agreement on when to use a checked exception. IMHO, checked exceptions bring (much) more pain than (supposed) robustness. bq. UncheckedIOException is not a reasonable alternative. Why was it introduced in the JDK? bq. A method that can neither handle nor throw IOException must not perform I/O operations. A developer could decide to never use checked exceptions; writing a program will still be possible. Some programming languages even made that decision for all developers. ;-) bq. It's worth noting that functional programming, not just in Java but in general, does not allow I/O. As soon as a method performs I/O, it's no longer a pure function and should not be written in a functional style. Such a rule could indeed be useful to limit the trend that everything is "forced" into functional style seemingly to save a couple of lines (while a side-effect is often that it becomes much less readable). > FileUtils.deleteDirectory can throw UncheckedIOException > -------------------------------------------------------- > > Key: IO-814 > URL: https://issues.apache.org/jira/browse/IO-814 > Project: Commons IO > Issue Type: Bug > Affects Versions: 2.13.0, 2.14.0 > Reporter: Elliotte Rusty Harold > Priority: Critical > > This was a behavior breaking change, and an incorrect one to boot. > Operations that can have I/O errors should throw IOException if they can't > directly handle the I/O error. UncheckedIOException is not a reasonable > alternative. > A method that can neither handle nor throw IOException must not perform I/O > operations. > It's worth noting that functional programming, not just in Java but in > general, does not allow I/O. As soon as a method performs I/O, it's no longer > a pure function and should not be written in a functional style. -- This message was sent by Atlassian Jira (v8.20.10#820010)