[
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" <[EMAIL PROTECTED]>
> To: <[email protected]>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
