[
https://issues.apache.org/jira/browse/CONFIGURATION-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715571#action_12715571
]
Emmanuel Bourg commented on CONFIGURATION-384:
----------------------------------------------
I wouldn't say the exception is buried. If the RuntimeException is chained with
the ConfigurationException no information is lost on the trace. And loading the
configuration in a static block without handling the exception is dangerous
since you are likely to break your application with no hope to recover from it
(providing a default configuration instead is a common pattern). You are free
to ignore the exception, but it's checked nature reminds you that something can
go wrong before you actually notice it.
> 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: mjh
> 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.
