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 Fri, 27 Jun 2008 13:54:46 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

if we're moving the core to java6, marking at WONTFIX; no longer needed

> 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