You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "private (JIRA)" <ji...@apache.org> on 2009/06/02 15:41:07 UTC
[jira] Created: (CONFIGURATION-384) ConfigurationException is a
checked exception; should be unchecked (ie: subclass of RuntimeException)
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
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.
[jira] Updated: (CONFIGURATION-384) ConfigurationException is a
checked exception; should be unchecked
Posted by "Emmanuel Bourg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Bourg updated CONFIGURATION-384:
-----------------------------------------
Component/s: (was: Events & Notifications)
Description:
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.
was:
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.
Priority: Minor (was: Major)
Environment: (was: N/A)
Issue Type: Wish (was: Bug)
Remaining Estimate: (was: 0.08h)
Original Estimate: (was: 0.08h)
Summary: ConfigurationException is a checked exception; should be unchecked (was: ConfigurationException is a checked exception; should be unchecked (ie: subclass of RuntimeException))
> 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
>
> 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.
[jira] Commented: (CONFIGURATION-384) ConfigurationException is a
checked exception; should be unchecked (ie: subclass of RuntimeException)
Posted by "Emmanuel Bourg (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CONFIGURATION-384) ConfigurationException is a
checked exception; should be unchecked
Posted by "Emmanuel Bourg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Bourg updated CONFIGURATION-384:
-----------------------------------------
Fix Version/s: 2.0
> 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.0
>
>
> 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.
[jira] Commented: (CONFIGURATION-384) ConfigurationException is a
checked exception; should be unchecked (ie: subclass of RuntimeException)
Posted by "private (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CONFIGURATION-384) ConfigurationException is a
checked exception; should be unchecked (ie: subclass of RuntimeException)
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715533#action_12715533 ]
Ralph Goers commented on CONFIGURATION-384:
-------------------------------------------
I have two comments on this.
1. The general rule on exceptions is to use checked exceptions for those exceptions that the caller can possibly handle and use unchecked (runtime) exceptions for those they normally can't. It is not always easy to determine what an application will be able to handle or not, but it is likely that at least some of the exceptions generated by Commons Configuration can be handled.
2. Commons Configuration already has two exceptions that it throws; ConfigurationException and ConfigurationRuntimeException. As one would imagine, ConfigurationException is a checked exception and ConfigurationRuntimeException is unchecked.
This issue is opened as a fairly general "request" to change all ConfigurationExceptions to ConfigurationRuntimeExceptions. I would be opposed to that. However, there are probably cases where this should be done, so this issue will be left open until we can inspect the code and insure that exceptions are being thrown properly.
It would be helpful to point out just where a runtime exception makes more sense than a checked 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.
[jira] Commented: (CONFIGURATION-384) ConfigurationException is a
checked exception; should be unchecked (ie: subclass of RuntimeException)
Posted by "mjh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715589#action_12715589 ]
mjh commented on CONFIGURATION-384:
-----------------------------------
It is buried as a nested exception inside the RuntimeException, when it is actually a configuration exception that has occurred. There is no loss of information here but there is a loss of clarity. Note that ConfigurationException is already itself nestable -- why add yet more clutter?
The point here is: the decision of whether config exceptions should be fatal, propagated, etc should be in the hands of the programmer, with the default being the most easy to use. The documentation already clearly lists all the places where ConfigurationExceptions are thrown.
Any serious application would be catching all exceptions whether they are checked or unchecked. For a small-medium application, terminating with a ConfigurationException because a config file can't be found is perfectly reasonable.
Requiring try/catch blocks for virtually every library access is also asking for the dreaded try {} catch ( Exception ignore ) {} syndrome, especially when those calls are likely to be perceived by users of your library as being trivial to the core functionality of the application.
> 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.
[jira] Commented: (CONFIGURATION-384) ConfigurationException is a
checked exception; should be unchecked (ie: subclass of RuntimeException)
Posted by "Emmanuel Bourg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715536#action_12715536 ]
Emmanuel Bourg commented on CONFIGURATION-384:
----------------------------------------------
Commons Configuration uses checked exceptions for loading the configuration, and unchecked exceptions for properties conversion errors. That's a good balance to me between ease of use and strict error handling.
> 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.
[jira] Issue Comment Edited: (CONFIGURATION-384)
ConfigurationException is a checked exception; should be unchecked (ie:
subclass of RuntimeException)
Posted by "mjh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715589#action_12715589 ]
mjh edited comment on CONFIGURATION-384 at 6/2/09 10:09 AM:
------------------------------------------------------------
It is buried as a nested exception inside the RuntimeException, when it is actually a configuration exception that has occurred. There is no loss of information here but there is a loss of clarity. Note that ConfigurationException is already itself nestable -- why add yet more clutter?
The point here is: the decision of whether config exceptions should be fatal, propagated, etc should be in the hands of the programmer, with the default being the most easy to use. The documentation already clearly lists all the places where ConfigurationExceptions are thrown.
Any serious application would be catching all exceptions whether they are checked or unchecked. For a small-medium application, terminating with a ConfigurationException because a config file can't be found is perfectly reasonable.
Requiring try/catch blocks for virtually every library access is also asking for the dreaded try {} catch ( Exception ignore ) {} syndrome, especially when those calls are likely to be perceived by users of your library as being trivial to the core functionality of the application. For such calls, try/catch code is just unnecessary clutter.
was (Author: mjh):
It is buried as a nested exception inside the RuntimeException, when it is actually a configuration exception that has occurred. There is no loss of information here but there is a loss of clarity. Note that ConfigurationException is already itself nestable -- why add yet more clutter?
The point here is: the decision of whether config exceptions should be fatal, propagated, etc should be in the hands of the programmer, with the default being the most easy to use. The documentation already clearly lists all the places where ConfigurationExceptions are thrown.
Any serious application would be catching all exceptions whether they are checked or unchecked. For a small-medium application, terminating with a ConfigurationException because a config file can't be found is perfectly reasonable.
Requiring try/catch blocks for virtually every library access is also asking for the dreaded try {} catch ( Exception ignore ) {} syndrome, especially when those calls are likely to be perceived by users of your library as being trivial to the core functionality of the application.
> 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.
[jira] Commented: (CONFIGURATION-384) ConfigurationException is a
checked exception; should be unchecked (ie: subclass of RuntimeException)
Posted by "Emmanuel Bourg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715611#action_12715611 ]
Emmanuel Bourg commented on CONFIGURATION-384:
----------------------------------------------
Fortunately Commons Configuration doesn't throw a checked exception on every API call. Actually, the Configuration interface declares no checked exception. You find them only on creating the concrete implementation, the configuration usage is exception free if you don't want to care. The checked exceptions only appear when you load/save the configuration, which is quite sensible.
> 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.