commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Bourg (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CONFIGURATION-384) ConfigurationException is a checked exception; should be unchecked
Date Tue, 02 Jun 2009 18:25:07 GMT

     [ 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.


Mime
View raw message