velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Bubna <>
Subject Re: RuntimeExceptions
Date Tue, 03 Jan 2006 16:18:56 GMT
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. :)

On 1/2/06, Will Glass-Husain <> wrote:
> 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
> * 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
> 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,
> _______________________________________
> Forio Business Simulations
> Will Glass-Husain
> phone (415) 440-7500 x89
> mobile (415) 235-4293

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

View raw message