You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Daniel Dekany <dd...@freemail.hu> on 2002/03/23 19:24:33 UTC
No way to catch runtime errors?
I would like to abort template processing when an error is logged, so the
template will not run onward in a corrupted state (eg. after null-sets) and
last not least the designer will see that (s)he did a mistake for sure.
Also I would like to log and abort template processing on invalid references
and invalid directive/macro calls (like #esle).
Any idea?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: No way to catch runtime errors?
Posted by Daniel Dekany <dd...@freemail.hu>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
Sent: Sunday, March 24, 2002 12:00 PM
> On 3/24/02 5:28 AM, "Daniel Dekany" <dd...@freemail.hu> wrote:
>
[snip]
> >>> 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).
>
> But not for applications. There's a long-standing philosophy to keep apps
> out of the core. Event handling is an app function.
Ahh, I see. I adopt the argument. Then pass a VelocityEngine. That's for
apps, right?
(A little technical complication: AFAIK inside Velocity engine the class
VelocityEngine is not very in use, but RunntimeInstance class and
RunntimeServices interface is. So perhaps we don't have a VelocityEngine
instance that we can send to the event handler. Altrought VelocityEngine is
just a very thin wrapper over a RunntimeInstance (as it exists today) it
would not be a good idea to create a new instance for every event calls. So
perhaps we could store one instance in the RunntimeInstance and pull it out
when needed.)
> > Error handlers are created to influence the operation of
> > Velocity core.
>
> Actually, they are called event handlers, and their purpose is to give the
> application code finer ability and control in the rendering process.
Then we have talked about two different things here. I don't stick to event
handlers. I just want error handling (which may can be implemented with
event handlers).
[snip]
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: No way to catch runtime errors?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/24/02 5:28 AM, "Daniel Dekany" <dd...@freemail.hu> wrote:
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> Sent: Sunday, March 24, 2002 2:14 AM
>
>
>> On 3/23/02 7:58 PM, "Daniel Dekany" <dd...@freemail.hu> wrote:
>>
>>> ----- Original Message -----
>>> From: "Geir Magnusson Jr." <ge...@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).
But not for applications. There's a long-standing philosophy to keep apps
out of the core. Event handling is an app function.
> Error handlers are created to influence the operation of
> Velocity core.
Actually, they are called event handlers, and their purpose is to give the
application code finer ability and control in the rendering process.
> Why don't give them the right to access the runtime services?
Because we don't want to expose them to apps so we can keep the freedom to
change as we wish. The app interfaces are well defined and we will stick to
that contract.
> Who is allowed to use runtime services then? And BTW, how should app code
> access the services of velocty?
Use the Velocity or VelocityEngine.
> 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.
>
Ok. The semantics are up to you.
Gotta catch a plane - more later...
Geir
[snip]
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: No way to catch runtime errors?
Posted by Daniel Dekany <dd...@freemail.hu>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
Sent: Sunday, March 24, 2002 2:14 AM
> On 3/23/02 7:58 PM, "Daniel Dekany" <dd...@freemail.hu> wrote:
>
> > ----- Original Message -----
> > From: "Geir Magnusson Jr." <ge...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: No way to catch runtime errors?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/23/02 7:58 PM, "Daniel Dekany" <dd...@freemail.hu> wrote:
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@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 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.
> 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...
>
>> 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
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.
This is something that certainly requires some contemplation....
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: No way to catch runtime errors?
Posted by Daniel Dekany <dd...@freemail.hu>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
Sent: Saturday, March 23, 2002 10:11 PM
[snip]
> > I think we should to add error handler events:
> > - Add event to catch invalid references (since $cutomre will not cause
parse
> > 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,
but
> > it does not allow me to log and abort the processing, so it is not
suitable
> > for error handling.
> >
>
>
> The first and third above is doable, and we talked about it. The second
is
> doable also.
>
> We want to be conservative about error handlers. We can add error
handlers
> out the wazoo for anything and everything, but I think we should really
only
> 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
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? 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.
[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.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: No way to catch runtime errors?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/23/02 4:06 PM, "Daniel Dekany" <dd...@freemail.hu> wrote:
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> Sent: Saturday, March 23, 2002 7:43 PM
>
>
>> On 3/23/02 1:24 PM, "Daniel Dekany" <dd...@freemail.hu> wrote:
>>
>>> I would like to abort template processing when an error is logged, so
> the
>>> template will not run onward in a corrupted state (eg. after null-sets)
> and
>>> last not least the designer will see that (s)he did a mistake for sure.
>>> Also I would like to log and abort template processing on invalid
> references
>>> and invalid directive/macro calls (like #esle).
>>> Any idea?
>>
>> Well, you can catch the parse exceptions... We can add an event for null
>> set.
>
> I think we should to add error handler events:
> - Add event to catch invalid references (since $cutomre will not cause parse
> 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, but
> it does not allow me to log and abort the processing, so it is not suitable
> for error handling.
>
The first and third above is doable, and we talked about it. The second is
doable also.
We want to be conservative about error handlers. We can add error handlers
out the wazoo for anything and everything, but I think we should really only
add those that really are useful.
> 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
very cautious about that. Context, yep. Other error stuff? If appropos.
Want to stop processing? Just throw an exception.
>> An easy way would be to make a logger and look for errors being sent to
>> it...
>
> Yes, but log LogSystem.logVelocityMessage does not allows me to abort
> template processing. (Or just I'm lame. How could I do that?)
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
My inner cowboy needs to yodel.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: No way to catch runtime errors?
Posted by Daniel Dekany <dd...@freemail.hu>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
Sent: Saturday, March 23, 2002 7:43 PM
> On 3/23/02 1:24 PM, "Daniel Dekany" <dd...@freemail.hu> wrote:
>
> > I would like to abort template processing when an error is logged, so
the
> > template will not run onward in a corrupted state (eg. after null-sets)
and
> > last not least the designer will see that (s)he did a mistake for sure.
> > Also I would like to log and abort template processing on invalid
references
> > and invalid directive/macro calls (like #esle).
> > Any idea?
>
> Well, you can catch the parse exceptions... We can add an event for null
> set.
I think we should to add error handler events:
- Add event to catch invalid references (since $cutomre will not cause parse
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, but
it does not allow me to log and abort the processing, so it is not suitable
for error handling.
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.
> An easy way would be to make a logger and look for errors being sent to
> it...
Yes, but log LogSystem.logVelocityMessage does not allows me to abort
template processing. (Or just I'm lame. How could I do that?)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: No way to catch runtime errors?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/23/02 1:24 PM, "Daniel Dekany" <dd...@freemail.hu> wrote:
> I would like to abort template processing when an error is logged, so the
> template will not run onward in a corrupted state (eg. after null-sets) and
> last not least the designer will see that (s)he did a mistake for sure.
> Also I would like to log and abort template processing on invalid references
> and invalid directive/macro calls (like #esle).
> Any idea?
Well, you can catch the parse exceptions... We can add an event for null
set.
An easy way would be to make a logger and look for errors being sent to
it...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
My inner cowboy needs to yodel.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>