Mailing-List: contact velocity-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Velocity Developers List" <velocity-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <008701c61086$3c621200$0a01a8c0@lfalco>
Reply-To: "Llewellyn Falco" <isidore@setgame.com>
From: "Llewellyn Falco" <isidore@setgame.com>
To: "Velocity Developers List" <velocity-dev@jakarta.apache.org>
References: <01ef01c60fad$c7390700$6500a8c0@Apollo>
Subject: Re: RuntimeExceptions
Date: Tue, 3 Jan 2006 08:53:34 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

+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.


I wanted to talk a bit about the Uberspect & the Testable Uberspect.

I think it is a very good thing to develop with the Testable, since it will 
catch mistakes in velocity simply and obviously.

which can really make development much less frustrating.


and for this reason, would wonder if it might be  a good default, because 
beginners( to anything)  tend to get frustrated easily


That said, the LoggingUberspect  (the current one) has obvious advantages in 
Production because at that level you are not going to be there to fix 
things, and if something goes wrong you don't want the page to be completely 
gone because a small portion might not have been displayed right.


of course, i would argue, that by the time you reach production, you have 
lost you beginner status :-)


llewellyn.


----- Original Message ----- 
From: "Will Glass-Husain" <wglass@forio.com>
To: <velocity-dev@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


_______________________________________
Forio Business Simulations

Will Glass-Husain
phone (415) 440-7500 x89
mobile (415) 235-4293
wglass@forio.com
www.forio.com 


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org