Sean Legassick wrote:
>
> On Tue, Feb 27, 2001 at 08:00:31AM -0500, Geir Magnusson Jr. wrote:
>
> > Just to summarize so it's clear - you are not looking for invocation
> > exceptions to be thrown (because those are a natural part of the
> > introspection flail-o-matic in some places, but any exceptions *your*
> > methods throw to propogate, right?
>
> Yep, absolutely (although given enough prodding of an invocation
> exception one can get at the heart of the problem anyway, but it
> probably makes sense to strip that layer away - like you say its just
> part of the introspection mechanism gubbins)...
I was thinking about this and looking through the code.
I think its a good idea to propagate exceptions from method invocations
out through Template.merge().
I can enumerate why if anyone needs details - the short answer is that I
think that you need to know during runtime, in the Controller layer,
when something goes wrong. That way you can do something intelligent,
like switch templates, email the admin, panic, whatever :)
This will turn out to be very important in the 'Pull Model' - there is
no other way that an application can gracefully recover from an error -
the template shouldn't have to deal with it. (Users calling saying the
site is hosed doesn't cut it either... :)
It will take a little care and work (so I am not doing it tonight - too
fogged in - and wanted to solicit opinions...)
To summarize :
public void merge( Context context, Writer writer)
throws ResourceNotFoundException, ParseErrorException, Exception
where Exception can also be exceptions thrown from in-context method
invocations.
We can make a new exception (one of the o.a.v.e set), but I don't really
see any point.
The public API won't change at all, so no code should notice (other than
they have a chance to deal with problems.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
