[
https://issues.apache.org/jira/browse/HADOOP-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507767#comment-13507767
]
Suresh Srinivas commented on HADOOP-9094:
-----------------------------------------
bq. The downside to #2 is you cannot interrogate the exception for the path
that had the problem. You'd be forced to mince the message string which is one
of the other reasons I made them subclasses of PathIOException.
Question is why is this necessary? This is an error condition and what can you
programmatically do?
bq. Multiple catch clauses would be required to handle path exceptions, FNF,
ACE, etc. Any ideas on how to avoid this?
One could then catch IOException, no?
I feel adding equivalent exceptions already available in java and used in
hadoop code to me seems unnecessary, even at the expense of losing some
grouping.
> Add interface audience and stability annotation to PathExceptions
> -----------------------------------------------------------------
>
> Key: HADOOP-9094
> URL: https://issues.apache.org/jira/browse/HADOOP-9094
> Project: Hadoop Common
> Issue Type: Bug
> Components: fs
> Affects Versions: 3.0.0
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
>
> HADOOP-9093 moved path related exceptions to o.a.h.fs. This jira tracks
> adding interface audience and stability to notation to those exceptions. It
> also tracks the comment from HADOOP-9093:
> bq. I propose using FileNotFoundException instead of PathNotFoundException as
> it is already extensively used. Similarly use AccessControlException instead
> of PathAccessException. If folks agree, I will make that change in the next
> patch. Alternatively we could at least make these exceptions subclasses of
> the exception that I am proposing replacing them with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
