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] Created: (HADOOP-3584) Add an explicit HadoopConfigurationException that extends RuntimeException
Date Tue, 17 Jun 2008 13:41:45 GMT
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.


Mime
View raw message