[
https://issues.apache.org/jira/browse/CONFIGURATION-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715562#action_12715562
]
private commented on CONFIGURATION-384:
---------------------------------------
I would contend it is not easy to use, nor logical for the most common use
cases.
eg: initialising your configuration in a static initialiser block ( class
MyClass { static { /* load my config */ } } ) -- you are obligated to wrap
your config initialisation in a try/catch specifically to catch the unchecked
ConfigurationException, and then either ignore it (which is probably bad), or
more likely, wrap it in a RuntimeException that you can throw, which is also
bad as it obfuscates the ConfigurationException by burying it in a totally
arbitrary wrapping exception.
> ConfigurationException is a checked exception; should be unchecked (ie:
> subclass of RuntimeException)
> -----------------------------------------------------------------------------------------------------
>
> Key: CONFIGURATION-384
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-384
> Project: Commons Configuration
> Issue Type: Bug
> Components: Events & Notifications
> Affects Versions: 1.6
> Environment: N/A
> Reporter: private
> Original Estimate: 0.08h
> Remaining Estimate: 0.08h
>
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
