[
https://issues.apache.org/jira/browse/HADOOP-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15120616#comment-15120616
]
Chris Douglas commented on HADOOP-12726:
----------------------------------------
{{java.io.InterruptedIOException}} serves a different purpose (albeit
incompletely), to allow I/O stacks to reason about which data were
acknowledged/believed to be durable when the thread was interrupted. It _also_
has the effect of not littering all APIs with {{InterruptedException}}, but
it's not purely intended as a tunnel through the type system, as
{{UnsupportedIOOperationException}} would be.
{{FileSystem}} is a public API, but implementations _routinely_ throw
{{UnsupportedOperationException}}. Particularly as they're layered over
compression libraries, encryption libraries, etc. that are also pluggable.
Exceptions are part of the semantics, you are entirely correct on that point,
but throwing an {{IOException}} for unsupported operations requires
justification, not the other way around. Even if we want to label this as
incompatible, we can still fix it in trunk.
> Unsupported operations should throw UnsupportedOperationException
> -----------------------------------------------------------------
>
> Key: HADOOP-12726
> URL: https://issues.apache.org/jira/browse/HADOOP-12726
> Project: Hadoop Common
> Issue Type: Improvement
> Components: fs
> Affects Versions: 2.7.1
> Reporter: Daniel Templeton
> Assignee: Daniel Templeton
>
> In the {{FileSystem}} implementation classes, unsupported operations throw
> {{new IOException("Not supported")}}, which makes it needlessly difficult to
> distinguish an actual error from an unsupported operation. They should
> instead throw {{new UnsupportedOperationException()}}.
> It's possible that this anti-idiom is used elsewhere in the code base. This
> JIRA should include finding and cleaning up those instances as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
