[
https://issues.apache.org/jira/browse/CONFIGURATION-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger updated CONFIGURATION-384:
---------------------------------------
Fix Version/s: (was: 2.0)
2.x
> ConfigurationException is a checked exception; should be unchecked
> ------------------------------------------------------------------
>
> Key: CONFIGURATION-384
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-384
> Project: Commons Configuration
> Issue Type: Wish
> Affects Versions: 1.6
> Reporter: mjh
> Priority: Minor
> Fix For: 2.x
>
>
> There's a movement in the field to simplify Java development by using
> unchecked Exceptions rather than checked Exceptions. Most notably this
> approach has been championed by Rod Johnson (J2EE without EJB, Spring
> Framework) and Bruce Eckels (Thinking in Java). In the last 2 years, popular
> libraries like Spring Framework and Hibernate 3.0 have used unchecked
> exceptions.
> Quote from the DeveloperWorks article listed below:
> "Some exceptions are basically secondary return codes (which generally signal
> violation of business rules), and some are of the "something went horribly
> wrong" variety (such as failure to make a database connection). Johnson
> advocates using checked exceptions for the first category (alternative return
> codes), and runtime exceptions for the latter category. In the "something
> went horribly wrong" category, the motivation is simply to recognize the fact
> that no caller is going to effectively handle this exception, so it might as
> well get propagated all the way up the stack with the minimum of impact on
> the intervening code (and minimize the chance of exception swallowing)."
> I have listed this as a bug rather than an improvement as it is common for
> developers to simply wrap configuration sections in a try { .. } catch (
> ConfigurationException ignore ) {}, which inevitably leads to buggy code
> further down the line.Even if the ConfigurationException is caught, it is
> likely to be wrapped in a RuntimeException subclass for reporting, which is
> also unnecessarily obtuse.
> It makes sense for this Exception to be unchecked (RuntimeException subclass)
> so that developers can decide whether the exception condition is worthy of
> catching or should be allowed to propagate as best suits their application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
