velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henning P. Schmiedehausen" <>
Subject Re: RuntimeExceptions
Date Fri, 13 Jan 2006 13:14:01 GMT
"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


>* 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

>(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

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:

View raw message