[
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)
