hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HADOOP-3584) Add an explicit HadoopConfigurationException that extends RuntimeException
Date Tue, 07 Jun 2016 08:18:21 GMT

     [ 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

To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org

View raw message