velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Dekany" <ddek...@freemail.hu>
Subject Re: No way to catch runtime errors?
Date Sun, 24 Mar 2002 10:28:19 GMT
----- Original Message -----
From: "Geir Magnusson Jr." <geirm@optonline.net>
Sent: Sunday, March 24, 2002 2:14 AM


> On 3/23/02 7:58 PM, "Daniel Dekany" <ddekany@freemail.hu> wrote:
>
> > ----- Original Message -----
> > From: "Geir Magnusson Jr." <geirm@optonline.net>
> > Sent: Saturday, March 23, 2002 10:11 PM
> >
>
> >
> >>> 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
> > let
> >>> LogSystem decide if it wants to abort the processing or not. But AFAIK
> > this
> >>> is not possible now, see below.
> >>
> >> Not sure we pass in the rsvc.  The error handler is app code, and want
to
> > be
> >
> > But how can I log without the rsvc?
>
> I can give you a logger.

And if I need to read a runtime property, then you give me a property reader
too?
Why are you reluctant about passing the rsvc? This is a public interface
(RuntimeServices). Error handlers are created to influence the operation of
Velocity core. Why don't give them the right to access the runtime services?
Who is allowed to use runtime services then? And BTW, how should app code
access the services of velocty? I miss rsvc in non-error-event handlers too,
like reference insertion handlers. Perhaps there should be some kind of
"RuntimeServicesForApps" interface which is a restricted version of the
RuntimeServices and thus less sensitive to the changes in the Velocity
engine, if this is why you don't want give rsvc.

> > And if the problem is that error handler
> > is an app code, then let say that it isn't. :)
>
> Lets not.
>
> > Think about error handlers as
> > some pluggable thing, like ResourceManagers are.
>
> Actually, since I cooked up the error handlers, I have a good idea how to
> think about them.
>
> They aren't the same as ResourceManagers, as each app defines their own,
in
> general, and you can have many different apps sharing the same Velocity
> engine, and therefore many different error handlers running through the
same
> Velocity engine, which will have a bunch of resource managers shared by
> those apps.

Event handlers like reference insertion is app code but as I imagined the
usage of *error* handlers  they are typically not app specific. That is, you
will use the same error handler classes for many Web applications. Error
handlers are to specify the behaviour of Velocity on errors. Eg. if you want
to abort processing on invalid references.
But anyway let call it app code then. The point is that it perhaps wants to
log, wants to get a property... etc.

> > 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.
>
> "In fact"?  I don't think that's a "fact" at all.  Error handlers were
> invented to allow an application to do a specific thing, namely escape XML
> entities...

An event handler which is triggered on reference insertions is obviously not
an error handler. I have writen about *error* handlers which in my
terminology is not the same as event handlers, but *maybe* is a subset of
event handlres.

> >
> >> very cautious about that.  Context, yep.  Other error stuff?  If
appropos.
> >>
> >> Want to stop processing?  Just throw an exception.
> > [snip]
> >
> > 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
> > processing.
>
> Or since the event handler is app code, you should be able to signal to
your
> app that things have gone wrong and not output to the client.  Being able
to

Yes but I still want to stop template processing of course. I can "redirect"
the output stream into the trash, but then I want to stop the output
generatig too. And if I can stop rendering then I need not "redirect" the
writer. That is, I want simply stop rendering.

> stop rendering is a dicey thing - especially if you are wrapping around
the
> output pipe to the client - the client will get an incomplete render.

When the trouble (the error) has already hapend then what ever you do, the
client will not be happy. And it is far better to return an incomplete
request (and try to close the stream with an error message) than to show
some wrong and possibly unauthorized private information.

> This is something that certainly requires some contemplation....

This is a problem that Velocity does not address seriously the problem of
render-time errors. First of all, *all* errors need to be catched somehow.
Perhaps it can be done with events and/or with the log, etc. If we use the
log to stop rendering (I don't like the idea) then perhaps we need to add a
new error level to the LogSystem, something like UNRECOVERABLE_ERROR_ID, and
then we still need a mechanism to specify if something is an (unrecoverable)
error or not (eg. if invalid reference is an error or not). (And what's if I
would like to stop rendering but I don't want to log.) So IMO instead we
should use an  error handler instance (a new class), which has a singe entry
ponit for errors (errors: I mean here all situations that possibly can be
considered as an error, eg. invalid references), and two methods to
add/remove user defined error event handlers. The error handler have to
decide what action to perform  (including stop rendering or ignore error)
based on the received error. The decision is made by dispatching the errors
to the user defined error event handlers or when no handler has been added
for an error type, the decision is made based on runtime propertyes. I see
in advance that you will say that I want to bloat the core... but hey,
errors must be handled correctly somehow and what Velocity offers now in
this field is... well... at best incomplete. I hope you will not say that
error handling is some kind of finery that should not be addressed by the
core. And perhaps first we need a list (or rather a tree) about what the
possible render-time errors are.
Then what is if we stop rendering. IMO Template.merge should throw an
exception (something like RenderingAbortedException) and then the caller can
catch it and do what it wants to do. Eg.: It will reset the Writer if it was
not commited and send an error page. And if the Writer was commited then it
will try to finish the output with an error message. This last is really
sucks, but -- irrespective of Velocity -- what else can you do?


--
To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>


Mime
View raw message