[ 
https://issues.apache.org/jira/browse/HADOOP-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506957#comment-13506957
 ] 

Suresh Srinivas commented on HADOOP-9094:
-----------------------------------------

bq. I had considered that when I created these exceptions, but wanted all path 
exceptions to derive from a common class. I suppose PathException could be an 
interface and we copy-n-paste the base code - which is the main factor I chose 
to derive from a base class.

Given that the new exceptions format the exception message in certain way, 
making the following change:
# Move the message formatting to a static method
# Have PathNotFoundException subclass FileNotFoundException. It formats the 
exception message using the utility.
# PathAccessException - rename it as PathAccessControlException. Make it a 
subclass of AccessControlException. It also formats the exception message using 
the utility.

Other alternative is to blow away the Path*Exception in above cases and use the 
super class I have propose. The message in the exception can still use the 
utility to format the message.

I am leaning towards the second option.
                
> 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

Reply via email to