velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Dekany" <>
Subject Re: No way to catch runtime errors?
Date Sun, 24 Mar 2002 00:58:49 GMT
----- Original Message -----
From: "Geir Magnusson Jr." <>
Sent: Saturday, March 23, 2002 10:11 PM

> > I think we should to add error handler events:
> > - Add event to catch invalid references (since $cutomre will not cause
> > exception)
> > - Add event to catch invalid directive/macro names (since #esle will not
> > cause parse exception).
> > - Add event to catch null sets. BTW event for null sets already exists,
> > it does not allow me to log and abort the processing, so it is not
> > for error handling.
> >
> The first and third above is doable, and we talked about it.  The second
> doable also.
> We want to be conservative about error handlers.  We can add error
> out the wazoo for anything and everything, but I think we should really
> add those that really are useful.

Velocity tends to silently step over errors. I think it is needless to
explain how wrong it can be, any programmer knows it. So it will be really
bad if you can't catch *ALL* errors and handle them in a way what is the
best for your app and development phase.

> > I think an error handling event needs:
> > - rsvc
> > - the context (if applicable)
> > - other error specific information
> > - A way to singal if the processing should aborted. Perhaps a string as
> > return value which is an error message if we want to abort processing or
> > null if we don't want to. Another approach is to log an error and then
> > LogSystem decide if it wants to abort the processing or not. But AFAIK
> > is not possible now, see below.
> Not sure we pass in the rsvc.  The error handler is app code, and want to

But how can I log without the rsvc? And if the problem is that error handler
is an app code, then let say that it isn't. :) Think about error handlers as
some pluggable thing, like ResourceManagers are. So that it is not app code
but rather something that allows you to "configure" Velocity. In fact this
is why error handlers would used.

> very cautious about that.  Context, yep.  Other error stuff?  If appropos.
> Want to stop processing?  Just throw an exception.

Then it should be stated explicitly in the API documentation. Also, then the
event handler method should have some "throws", or I have to throw
RuntimeException which is ugly. It goes double for
LogSystem.logVelocityMessage, as throwing an exception may interpreted as
"failed to create the log entry" which is something that would not stop the

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

View raw message