[jira] [Resolved] (HADOOP-3584) Add an explicit HadoopConfigurationException that extends RuntimeException

["Steve Loughran (JIRA)" <ji...@apache.org>]

     [ 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-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org