[
https://issues.apache.org/jira/browse/HADOOP-12726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119842#comment-15119842
]
Daniel Templeton commented on HADOOP-12726:
-------------------------------------------
I really dislike the idea of replicating core functionality like that. I'd
also balk at creating Frankenstein's exception.
Is your concern that some bits of the system are catching {{IOException}} with
the expectation that they will also catch unsupported operations? I would
offer the argument that an unsupported operation is inherently a different
thing from an {{IOException}}. If some code is catching {{IOException}} to
deal with both, they're probably doing something wrong. I'd also be willing to
bet that in the only case where that approach is valid: log and exit, they're
catching {{Exception}} instead.
I think it should be pretty reasonable to go through the code to find all cases
of calls to potentially unsupported operations and make sure they handle an
{{UnsupportedOperationException}} correctly. That leaves client code at risk
of breaking, but that's where we started.
> 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)
