Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <1735422184.1213710105001.JavaMail.jira@brutus>
Date: Tue, 17 Jun 2008 06:41:45 -0700 (PDT)
From: "Steve Loughran (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Created: (HADOOP-3584) Add an explicit
 HadoopConfigurationException that extends RuntimeException
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Add an explicit HadoopConfigurationException that extends RuntimeException
--------------------------------------------------------------------------

                 Key: HADOOP-3584
                 URL: https://issues.apache.org/jira/browse/HADOOP-3584
             Project: Hadoop Core
          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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.