From: Tim Joyce [mailto:[EMAIL PROTECTED]]
> > > while we are talking about exceptions, you may have noticed
> > > that Webmacro
> > > has recently introduced an EvaluationExceptionHandler
> > > interface, allowing
> > > control over how exceptions that occur during template
> expansion are
> > > handled. are there any plans to do something similar in Velocity?
> >
> > I dunno. We aren't proud. If there is a need, we are
> happy to honor them
> > by blithely stealing their features :)
>
> i feel the need is great :)
It so appears...
>
> > It wouldn't be that hard to do with the EventCartridge mechanism, or
> > something similar.
>
> ok, i havn't been folowwing this thread.
It was the great 'XML Entity' debate. The code is in
whiteboard/geir/listener, and as there hasn't been any comment recently, it
should go in soon, I susppose.
> > That strikes me as just another event.
> >
> > But practically speaking, are you really going to want to
> deal with that
> on
> > an exception by exception basis? I'm a touch skeptical how much real
> > practical use it would get,
>
> essentially we like to do 2 things with exceptions:
>
> 1) render "inline", eithier as a comment string, or as
> somthing informative
> for the user.
Hm. WIth the EventCartridge, it allows you to define a handler for
'events'. Currently, we've identified a few events :
1) ReferenceInsertion - right before velocity inserts the rendered reference
ot the output stream, it can call a method which then can change what will
be output.
2) NullSet - when a #set($left = $right) has a null $right
3) something else (i forget...)
Anyway, one might add some sort of ExceptionHandler...
Just musing aloud, you can always (well, once that little bug is fixed)
figure out which reference/method caused the problem. Then one strategy
could be to simply replace it in the context with your comment string or
message, and remerge...
> 2) abandon the merge and do something appropiate depending
> on the exception
This you can do at the top level now.
> an example of practical usage is if you have an object in
> your context that
> has a property with restricted access.
>
> 1) you may want to nicely hide the restricted property:
> "sorry, you are not
> allowed to view user's passwords"
> 2) or you may want to redirect the user to a login page
Right. Some might argue it's 'proper' to sort out somthing like that in the
controller / model, rather than at View time, but whatever..
> > especially since you can capture the
> > merge()-time exceptions, deal with them, and remerge.
> That's just my
> > personal take...
>
> umm, i had trouble getting merge time exceptions out, i could
> only get a
> MethodInvocationException (hence the initial post). Perhaps
> i've missed
> something.
That MethodInvocationException should have within it the original Exception
thrown by your method via getWrappedThrowable()
See
http://jakarta.apache.org/velocity/api/org/apache/velocity/exception/MethodI
nvocationException.html
Yes, there is a bug in your $foo.Bar example (my fault), but once that's
fixed (later tonight), you can chuck exceptions with gay abandon, and catch
them all at the top wrapped in MethodInvocationExceptions. I hope. :)
geir
