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 2006/01/04 05:53:00 UTC
[jira] Created: (VELOCITY-429) Pass through runtime exceptions
Pass through runtime exceptions
-------------------------------
Key: VELOCITY-429
URL: http://issues.apache.org/jira/browse/VELOCITY-429
Project: Velocity
Type: Improvement
Components: Source
Reporter: Will Glass-Husain
Assigned to: Will Glass-Husain
Priority: Minor
Fix For: 1.5
Thought it might be useful to archive the brief discussion on this topic since it's a cross-cutting type of issue. I'm going to link to this issue in the change log.
----- Original Message -----
From: "Will Glass-Husain" <wg...@forio.com>
To: <ve...@jakarta.apache.org>
Sent: Monday, January 02, 2006 7:03 AM
Subject: RuntimeExceptions
First, happy new year to the Velocity developer community...
I've been pondering how Velocity handles exceptions. Right now, almost every call to a plugin has a catch-all Exception handler which does little more than log the Exception. There's been a couple of requests in the past few months to pass RuntimeExceptions or similar through.
* In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to pass through a #parse. (we did this).
* Llewelyn Falco created a "TestableUberspect" which interrupted processing upon an invalid method call.
* There was someone else (can't find the reference) who wanted to interrupt processing when confronted with an invalid method call.
I was wondering, why does Velocity intercept every exception? Isn't the point of a RuntimeException that it signals an application-level problem that should be returned to the calling code? In addition, we should allow plugins (event handlers, uberspectors, resource loaders) to interrupt processing for critical problems. To me, there seems three choices.
(1) Catch every unexpected condition and do something with it (e.g. catch NPE from toString() and wrap it in a MethodInvocationException). Logging does not count as doing something.
(2) Create a special VelocityRuntimeException that plugins can use to interrupt processing. Every generic catch (Exception E) wrapper would pass this through. (I've coded this though not applied the patch).
(3) Remove all generic Exception catch's. (or if not feasible, always pass RuntimeException's through).
To me, option #1 seems infeasible. (if we start wrapping toString, we'd need to wrap a lot of other little stuff). Option #2 is useful for plugins to interrupt processing. But I'm wondering, why not do option #3 and just pass through all RuntimeExceptions. Any reason why we *should* be catching unexpected RuntimeException's?
Appreciate other thoughts...
Best,
WILL
--
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] Resolved: (VELOCITY-429) Pass through runtime exceptions
Posted by "Will Glass-Husain (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-429?page=all ]
Will Glass-Husain resolved VELOCITY-429:
----------------------------------------
Resolution: Fixed
Update applied.
> Pass through runtime exceptions
> -------------------------------
>
> Key: VELOCITY-429
> URL: http://issues.apache.org/jira/browse/VELOCITY-429
> Project: Velocity
> Type: Improvement
> Components: Source
> Reporter: Will Glass-Husain
> Assignee: Will Glass-Husain
> Priority: Minor
> Fix For: 1.5
>
> Thought it might be useful to archive the brief discussion on this topic since it's a cross-cutting type of issue. I'm going to link to this issue in the change log.
> ----- Original Message -----
> From: "Will Glass-Husain" <wg...@forio.com>
> To: <ve...@jakarta.apache.org>
> Sent: Monday, January 02, 2006 7:03 AM
> Subject: RuntimeExceptions
> First, happy new year to the Velocity developer community...
> I've been pondering how Velocity handles exceptions. Right now, almost every call to a plugin has a catch-all Exception handler which does little more than log the Exception. There's been a couple of requests in the past few months to pass RuntimeExceptions or similar through.
> * In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to pass through a #parse. (we did this).
> * Llewelyn Falco created a "TestableUberspect" which interrupted processing upon an invalid method call.
> * There was someone else (can't find the reference) who wanted to interrupt processing when confronted with an invalid method call.
> I was wondering, why does Velocity intercept every exception? Isn't the point of a RuntimeException that it signals an application-level problem that should be returned to the calling code? In addition, we should allow plugins (event handlers, uberspectors, resource loaders) to interrupt processing for critical problems. To me, there seems three choices.
> (1) Catch every unexpected condition and do something with it (e.g. catch NPE from toString() and wrap it in a MethodInvocationException). Logging does not count as doing something.
> (2) Create a special VelocityRuntimeException that plugins can use to interrupt processing. Every generic catch (Exception E) wrapper would pass this through. (I've coded this though not applied the patch).
> (3) Remove all generic Exception catch's. (or if not feasible, always pass RuntimeException's through).
> To me, option #1 seems infeasible. (if we start wrapping toString, we'd need to wrap a lot of other little stuff). Option #2 is useful for plugins to interrupt processing. But I'm wondering, why not do option #3 and just pass through all RuntimeExceptions. Any reason why we *should* be catching unexpected RuntimeException's?
> Appreciate other thoughts...
> Best,
> WILL
--
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] Closed: (VELOCITY-429) Pass through runtime exceptions
Posted by "Henning Schmiedehausen (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henning Schmiedehausen closed VELOCITY-429.
-------------------------------------------
> Pass through runtime exceptions
> -------------------------------
>
> Key: VELOCITY-429
> URL: https://issues.apache.org/jira/browse/VELOCITY-429
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Reporter: Will Glass-Husain
> Assigned To: Will Glass-Husain
> Priority: Minor
> Fix For: 1.5
>
>
> Thought it might be useful to archive the brief discussion on this topic since it's a cross-cutting type of issue. I'm going to link to this issue in the change log.
> ----- Original Message -----
> From: "Will Glass-Husain" <wg...@forio.com>
> To: <ve...@jakarta.apache.org>
> Sent: Monday, January 02, 2006 7:03 AM
> Subject: RuntimeExceptions
> First, happy new year to the Velocity developer community...
> I've been pondering how Velocity handles exceptions. Right now, almost every call to a plugin has a catch-all Exception handler which does little more than log the Exception. There's been a couple of requests in the past few months to pass RuntimeExceptions or similar through.
> * In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to pass through a #parse. (we did this).
> * Llewelyn Falco created a "TestableUberspect" which interrupted processing upon an invalid method call.
> * There was someone else (can't find the reference) who wanted to interrupt processing when confronted with an invalid method call.
> I was wondering, why does Velocity intercept every exception? Isn't the point of a RuntimeException that it signals an application-level problem that should be returned to the calling code? In addition, we should allow plugins (event handlers, uberspectors, resource loaders) to interrupt processing for critical problems. To me, there seems three choices.
> (1) Catch every unexpected condition and do something with it (e.g. catch NPE from toString() and wrap it in a MethodInvocationException). Logging does not count as doing something.
> (2) Create a special VelocityRuntimeException that plugins can use to interrupt processing. Every generic catch (Exception E) wrapper would pass this through. (I've coded this though not applied the patch).
> (3) Remove all generic Exception catch's. (or if not feasible, always pass RuntimeException's through).
> To me, option #1 seems infeasible. (if we start wrapping toString, we'd need to wrap a lot of other little stuff). Option #2 is useful for plugins to interrupt processing. But I'm wondering, why not do option #3 and just pass through all RuntimeExceptions. Any reason why we *should* be catching unexpected RuntimeException's?
> Appreciate other thoughts...
> Best,
> WILL
--
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] Commented: (VELOCITY-429) Pass through runtime exceptions
Posted by "Will Glass-Husain (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-429?page=comments#action_12361707 ]
Will Glass-Husain commented on VELOCITY-429:
--------------------------------------------
Brief summary of comments...
Malcom Edgar:
+1 on Option #3. I think this is now accepted as a best practice with Java error handling.
Peter Urban:
Yes, please... it would make life with Velocity a lot easier!
Llewellyn Falco:
+1
I especially agree with the removal of any exception handling where the
handling is to log the error. as my log files are not read nearly often
enough for this to work.
Nathan Bubna:
hmm. i'm a bit skeptical of whether all the generic Exception catches
can be removed, but i'm pretty sure i'd be supportive of passing all
(or at least most) RuntimeExceptions through. i personally haven't
hit any problems with the current pattern, but i'm sure things could
be improved. +0.5 for option 3. :)
> Pass through runtime exceptions
> -------------------------------
>
> Key: VELOCITY-429
> URL: http://issues.apache.org/jira/browse/VELOCITY-429
> Project: Velocity
> Type: Improvement
> Components: Source
> Reporter: Will Glass-Husain
> Assignee: Will Glass-Husain
> Priority: Minor
> Fix For: 1.5
>
> Thought it might be useful to archive the brief discussion on this topic since it's a cross-cutting type of issue. I'm going to link to this issue in the change log.
> ----- Original Message -----
> From: "Will Glass-Husain" <wg...@forio.com>
> To: <ve...@jakarta.apache.org>
> Sent: Monday, January 02, 2006 7:03 AM
> Subject: RuntimeExceptions
> First, happy new year to the Velocity developer community...
> I've been pondering how Velocity handles exceptions. Right now, almost every call to a plugin has a catch-all Exception handler which does little more than log the Exception. There's been a couple of requests in the past few months to pass RuntimeExceptions or similar through.
> * In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to pass through a #parse. (we did this).
> * Llewelyn Falco created a "TestableUberspect" which interrupted processing upon an invalid method call.
> * There was someone else (can't find the reference) who wanted to interrupt processing when confronted with an invalid method call.
> I was wondering, why does Velocity intercept every exception? Isn't the point of a RuntimeException that it signals an application-level problem that should be returned to the calling code? In addition, we should allow plugins (event handlers, uberspectors, resource loaders) to interrupt processing for critical problems. To me, there seems three choices.
> (1) Catch every unexpected condition and do something with it (e.g. catch NPE from toString() and wrap it in a MethodInvocationException). Logging does not count as doing something.
> (2) Create a special VelocityRuntimeException that plugins can use to interrupt processing. Every generic catch (Exception E) wrapper would pass this through. (I've coded this though not applied the patch).
> (3) Remove all generic Exception catch's. (or if not feasible, always pass RuntimeException's through).
> To me, option #1 seems infeasible. (if we start wrapping toString, we'd need to wrap a lot of other little stuff). Option #2 is useful for plugins to interrupt processing. But I'm wondering, why not do option #3 and just pass through all RuntimeExceptions. Any reason why we *should* be catching unexpected RuntimeException's?
> Appreciate other thoughts...
> Best,
> WILL
--
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