velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Dekany" <>
Subject Re: Str. lit. interpolation and ReferenceInsertionEventHandler
Date Wed, 20 Mar 2002 23:03:08 GMT
On Wednesday, March 20, 2002 10:11 PM "Geir Magnusson Jr."
<> wrote:

> On 3/20/02 3:59 PM, "Sven Meier" <> wrote:
> > Hi,
> >
> >>>> I have another idea, why not pass the context in which the event was
> >>> fired
> >>>> to the event...
> >>>
> >>> Ok - but that's really a different thing.  We can still look at that
> >
> > does this mean that there are bigger changes for
> > ReferenceInsertionEventHandler to come ? In this case I'd like to throw
> > an old request of mine:
> >
> > The current RIE cannot distinguish invalid references and NULL values -
> > which is not always the same, e.g. when methods of objects in the
> > return NULL.
> Ya...  One solution there would be to pass in the context and let you
> out what you need.

The "null or invalid reference" problem exists in other situations too. Eg.
in case of $[$noSuchObject, $foo.willReturnNull()]) the ArrayList
will contain two null-s. To make things more complicated, invalid reference
does not always result in null. Eg. in case of  $$noSuchObject), will get a pure java.lang.Object as argument (BTW why???). So I
think that there should be a centralized point where you can handle error
conditions (like invalid references, or when RHS of #set statement is null)
in a customizable way. Perhaps there should be one event handlers per error
type. Then in the handler I can decide if want to abort the whole template
processing with an error message, or just log the error, or do some other
action to handle the problem. Note that IMO the RuntimeInstance should be
passed to all event handler methods (it goes for the current event handlers
too) so I can log messages, etc. Also, the VelocityContext should be passed
if it does sense for the event type.

Yes, we have NullSetEventHandler already, but it seems that it is created to
prevent even that little poor log entry. I really can't find out what is the
rationale behind this idea (i.e. hiding errors like null-set), but I know
that silently ignoring errors and then let the program flow onward is a
rather danegours behaviour. I'm really curious, since I can't find out: What
the is the good in hiding null-set-s? Personally I have writen a
NullSetEventHandler which throws a Big Big RuntimeException and thus aborts
template processing. Very ugly hack, but what else can I do? And I can't log
before the thow, since I have no reference to the RuntimeInstance in the

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

View raw message