velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Glass-Husain" <>
Subject Re: RuntimeExceptions
Date Fri, 13 Jan 2006 16:29:28 GMT
Hi Henning,

Good to hear from you.  I've recently committed this -- pass through all 
RuntimeExceptions-- except for those from method calls which go through the 
appropriate event handler.  (and throw a MethodInvocationException if 
appropriate).  In general though the consensus (which you seem to join) is 
that passing through the RuntimeException from a plugin is very appropriate.

If you think of other possible event handlers speak up.


----- Original Message ----- 
From: "Henning P. Schmiedehausen" <>
To: <>
Sent: Friday, January 13, 2006 5:14 AM
Subject: Re: RuntimeExceptions

> "Will Glass-Husain" <> writes:
>>First, happy new year to the Velocity developer community...
> Thanks Will, same to you and to all other people around here.
>>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. =20
> Yep.
>>* 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 =
> IMHO this was done at some point in the past when it was "en vogue" to 
> react
> on any exception or simply declare it up. But when you end up with a 
> method
> that "throws FooException, BarException, SQLException, XXXException", in 
> the
> end the user will simply surround it with "catch (Exception e)".
>>(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.
> Strong -1. At first, toString() shouldn't throw NPE. If it does, well
> then this is something that the user code must react on. For us, NPE
> is something that should either be propagated up or acted upon by an
> EventCartridge.
>>(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).
> -0. While in JDK 1.5 we have wrapable exceptions (and there are ways to
> emulate this in 1.4.x), I don't see the point. Why must everything throw
> the same exception?
>>(3) Remove all generic Exception catch's.  (or if not feasible, always =
>>pass RuntimeException's through).
> This seems to be the best solution of the three. However, we should
> still try to identify the different exception scenarios. Getting more
> event cartridges in to get act on problems might help here.
>>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?
> This points to the question whether a problem with method invocation
> on a context object should terminate template processing. Maybe an
> EventCartridge can help here.
> Best regards
> Henning
> -- 
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
>        +49 9131 50 654 0
> RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
>   Linux, Java, perl, Solaris -- Consulting, Training, Development
>       4 - 8 - 15 - 16 - 23 - 42
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message