[ 
https://issues.apache.org/jira/browse/HADOOP-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Wang updated HADOOP-3584:
--------------------------------
    Fix Version/s:     (was: 2.8.0)

> Add an explicit HadoopConfigurationException that extends RuntimeException
> --------------------------------------------------------------------------
>
>                 Key: HADOOP-3584
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3584
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: conf
>    Affects Versions: 0.19.0
>            Reporter: Steve Loughran
>            Priority: Minor
>
> It is possible for a get() or set() operation to throw an exception today, 
> especially if a security manager is blocking property access. As more complex 
> cross-references are used, the likelihood for failure is higher.
> Yet there is no way for a Configuration or subclass to throw an exception 
> today except by throwing a general purpose RuntimeException.
> I propose having a specific HadoopConfigurationException that extends 
> RuntimeException. Classes that read in configurations can explicitly catch 
> and handle these. The exception could
> * be raised on some parse error (a float attribute is not a parseable float, 
> etc)
> * be raised on some error caused by an implementation of a configuration 
> service API
> * wrap underlying errors from different implementations (like JNDI exceptions)
> * wrap security errors and other generic problems
> I'm not going to propose having specific errors for parsing problems versus 
> undefined name,value pair though that may be useful feature creep. It 
> certainly makes bridging from different back-ends trickier. 
> This would not be incompatible with the existing code, at least from my 
> current experiments. What is more likely to cause problems is having the 
> get() operations failing, as that is not something that is broadly tested 
> (yet). If we do want to test it, we could have a custom mock back-end that 
> could be configured to fail on a get() of a specific option.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

Reply via email to