[
https://issues.apache.org/jira/browse/HADOOP-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Loughran resolved HADOOP-3584.
------------------------------------
Resolution: Won't Fix
Fix Version/s: 2.8.0
Just noticed this JIRA hanging around. Clearly nobody else cares for it.
Closing for now
> 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
> Fix For: 2.8.0
>
>
> 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-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org
