You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Will Glass-Husain (JIRA)" <ji...@apache.org> on 2005/10/04 00:29:48 UTC
[jira] Created: (VELOCITY-409) Convert Exceptions to RuntimeExceptions
Convert Exceptions to RuntimeExceptions
---------------------------------------
Key: VELOCITY-409
URL: http://issues.apache.org/jira/browse/VELOCITY-409
Project: Velocity
Type: Improvement
Components: Source
Versions: 1.4
Reporter: Will Glass-Husain
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'd argue that Velocity exceptions like ParseException and ResourceNotFoundException are of the "horribly wrong" category. Probably MethodInvocationException as well. In version 2.0, we should consider making VelocityException a subclass of java.lang.RuntimeException.
Resources:
http://www-128.ibm.com/developerworks/java/library/j-jtp05254.html
Here's an argument against this practice:
http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [jira] Created: (VELOCITY-409) Convert Exceptions to RuntimeExceptions
Posted by Will Glass-Husain <wg...@forio.com>.
nice idea. Could you add that to the issue so we remember it?
WILL
----- Original Message -----
From: "Llewellyn Falco" <is...@setgame.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Monday, October 03, 2005 4:02 PM
Subject: Re: [jira] Created: (VELOCITY-409) Convert Exceptions to
RuntimeExceptions
> BIG +1 on this
> It would also be nice if the exceptions had methods, say ResourceNotFound
> could have a method like getResource() maybe getResourceLoaderPath()
>
>
> llewellyn.
>
>> Convert Exceptions to RuntimeExceptions
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [jira] Created: (VELOCITY-409) Convert Exceptions to RuntimeExceptions
Posted by Llewellyn Falco <is...@setgame.com>.
BIG +1 on this
It would also be nice if the exceptions had methods,
say ResourceNotFound could have a method like
getResource()
maybe
getResourceLoaderPath()
llewellyn.
> Convert Exceptions to RuntimeExceptions
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[jira] Closed: (VELOCITY-409) Convert Exceptions to
RuntimeExceptions
Posted by "Henning Schmiedehausen (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henning Schmiedehausen closed VELOCITY-409.
-------------------------------------------
> Convert Exceptions to RuntimeExceptions
> ---------------------------------------
>
> Key: VELOCITY-409
> URL: https://issues.apache.org/jira/browse/VELOCITY-409
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.4
> Reporter: Will Glass-Husain
> Priority: Minor
> Fix For: 1.5
>
>
> 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'd argue that Velocity exceptions like ParseException and ResourceNotFoundException are of the "horribly wrong" category. Probably MethodInvocationException as well. In version 2.0, we should consider making VelocityException a subclass of java.lang.RuntimeException.
> Resources:
> http://www-128.ibm.com/developerworks/java/library/j-jtp05254.html
> Here's an argument against this practice:
> http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Resolved: (VELOCITY-409) Convert Exceptions to
RuntimeExceptions
Posted by "Henning Schmiedehausen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-409?page=all ]
Henning Schmiedehausen resolved VELOCITY-409.
---------------------------------------------
Fix Version/s: 1.5
(was: 2.0)
Resolution: Fixed
We boldly moved VelocityException to extend RuntimeException between beta1 and beta2. Beware of flying pigs overhead. :-)
> Convert Exceptions to RuntimeExceptions
> ---------------------------------------
>
> Key: VELOCITY-409
> URL: http://issues.apache.org/jira/browse/VELOCITY-409
> Project: Velocity
> Issue Type: Improvement
> Components: Source
> Affects Versions: 1.4
> Reporter: Will Glass-Husain
> Priority: Minor
> Fix For: 1.5
>
>
> 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'd argue that Velocity exceptions like ParseException and ResourceNotFoundException are of the "horribly wrong" category. Probably MethodInvocationException as well. In version 2.0, we should consider making VelocityException a subclass of java.lang.RuntimeException.
> Resources:
> http://www-128.ibm.com/developerworks/java/library/j-jtp05254.html
> Here's an argument against this practice:
> http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[jira] Commented: (VELOCITY-409) Convert Exceptions to
RuntimeExceptions
Posted by "Henning Schmiedehausen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-409?page=comments#action_12432810 ]
Henning Schmiedehausen commented on VELOCITY-409:
-------------------------------------------------
I do second that notion. Runtime exceptions are the way to go. :-)
> Convert Exceptions to RuntimeExceptions
> ---------------------------------------
>
> Key: VELOCITY-409
> URL: http://issues.apache.org/jira/browse/VELOCITY-409
> Project: Velocity
> Issue Type: Improvement
> Components: Source
> Affects Versions: 1.4
> Reporter: Will Glass-Husain
> 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'd argue that Velocity exceptions like ParseException and ResourceNotFoundException are of the "horribly wrong" category. Probably MethodInvocationException as well. In version 2.0, we should consider making VelocityException a subclass of java.lang.RuntimeException.
> Resources:
> http://www-128.ibm.com/developerworks/java/library/j-jtp05254.html
> Here's an argument against this practice:
> http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org