First, happy new year to the Velocity developer community
I've been pondering how Velocity handles exceptions. Right now, almost every call to a plugin has a catch-all Exception handler which does little more than log the Exception. There's been a couple of requests in the past few months to pass RuntimeExceptions or similar through.
* In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to pass through a #parse. (we did this).
* Llewelyn Falco created a "TestableUberspect" which interrupted processing upon an invalid method call.
* There was someone else (can't find the reference) who wanted to interrupt processing when confronted with an invalid method call.
I was wondering, why does Velocity intercept every exception? Isn't the point of a RuntimeException that it signals an application-level problem that should be returned to the calling code? In addition, we should allow plugins (event handlers, uberspectors, resource loaders) to interrupt processing for critical problems. To me, there seems three choices.
(1) Catch every unexpected condition and do something with it (e.g. catch NPE from toString() and wrap it in a MethodInvocationException). Logging does not count as doing something.
(2) Create a special VelocityRuntimeException that plugins can use to interrupt processing. Every generic catch (Exception E) wrapper would pass this through. (I've coded this though not applied the patch).
(3) Remove all generic Exception catch's. (or if not feasible, always pass RuntimeException's through).
To me, option #1 seems infeasible. (if we start wrapping toString, we'd need to wrap a lot of other little stuff). #2 is useful for plugins to interrupt processing. But I'm wondering, why not do option #3 and just pass through all RuntimeExceptions. Any reason why we *should* be catching unexpected RuntimeException's?
Appreciate other thoughts
Best,
WILL
Forio Business Simulations
Will Glass-Husain
phone (415) 440-7500 x89
mobile (415) 235-4293
wglass (AT) forio (DOT) com
www.forio.com

+1 on #3.

I think this is now accepted as a best practice with Java error handling.

regards Malcolm Edgar

1/3/06, Will Glass-Husain <wglass (AT) forio (DOT) comwrote:
First, happy new year to the Velocity developer community

I've been pondering how Velocity handles exceptions. Right now, almost every call to a plugin has a catch-all Exception handler which does little more than log the Exception. There's been a couple of requests in the past few months to pass RuntimeExceptions or similar through.

* In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to pass through a #parse. (we did this).
* Llewelyn Falco created a "TestableUberspect" which interrupted processing upon an invalid method call.
* There was someone else (can't find the reference) who wanted to interrupt processing when confronted with an invalid method call.

I was wondering, why does Velocity intercept every exception? Isn't the point of a RuntimeException that it signals an application-level problem that should be returned to the calling code? In addition, we should allow plugins (event handlers, uberspectors, resource loaders) to interrupt processing for critical problems. To me, there seems three choices.

(1) Catch every unexpected condition and do something with it (e.g. catch NPE from toString() and wrap it in a MethodInvocationException). Logging does not count as doing something.

(2) Create a special VelocityRuntimeException that plugins can use to interrupt processing. Every generic catch (Exception E) wrapper would pass this through. (I've coded this though not applied the patch).

(3) Remove all generic Exception catch's. (or if not feasible, always pass RuntimeException's through).

To me, option #1 seems infeasible. (if we start wrapping toString, we'd need to wrap a lot of other little stuff). #2 is useful for plugins to interrupt processing. But I'm wondering, why not do option #3 and just pass through all RuntimeExceptions. Any reason why we *should* be catching unexpected RuntimeException's?

Appreciate other thoughts

Best,
WILL
>
>
>
>
>
>
>

Forio Business Simulations

Will Glass-Husain
phone (415) 440-7500 x89
mobile (415) 235-4293
wglass (AT) forio (DOT) com
www.forio.com

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

Hi Will,

+1 on #3.

I think this is now accepted as a best practice with Java error handling.

regards Malcolm Edgar

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

hmm. i'm a bit skeptical of whether all the generic Exception catches
can be removed, but i'm pretty sure i'd be supportive of passing all
(or at least most) RuntimeExceptions through. i personally haven't
hit any problems with the current pattern, but i'm sure things could
be improved. +0.5 for option 3. :)

1/2/06, Will Glass-Husain <wglass (AT) forio (DOT) comwrote:
First, happy new year to the Velocity developer community

I've been pondering how Velocity handles exceptions. Right now, almost every call to a plugin has a catch-all Exception handler which does little more than log the Exception. There's been a couple of requests in the past few months to pass RuntimeExceptions or similar through.

* In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to pass through a #parse. (we did this).
* Llewelyn Falco created a "TestableUberspect" which interrupted processing upon an invalid method call.
* There was someone else (can't find the reference) who wanted to interrupt processing when confronted with an invalid method call.

I was wondering, why does Velocity intercept every exception? Isn't the point of a RuntimeException that it signals an application-level problem that should be returned to the calling code? In addition, we should allow plugins (event handlers, uberspectors, resource loaders) to interrupt processing for critical problems. To me, there seems three choices.

(1) Catch every unexpected condition and do something with it (e.g. catch NPE from toString() and wrap it in a MethodInvocationException). Logging does not count as doing something.

(2) Create a special VelocityRuntimeException that plugins can use to interrupt processing. Every generic catch (Exception E) wrapper would pass this through. (I've coded this though not applied the patch).

(3) Remove all generic Exception catch's. (or if not feasible, always pass RuntimeException's through).

To me, option #1 seems infeasible. (if we start wrapping toString, we'd need to wrap a lot of other little stuff). #2 is useful for plugins to interrupt processing. But I'm wondering, why not do option #3 and just pass through all RuntimeExceptions. Any reason why we *should* be catching unexpected RuntimeException's?

Appreciate other thoughts

Best,
WILL
>
>
>
>
>
>
>

Forio Business Simulations

Will Glass-Husain
phone (415) 440-7500 x89
mobile (415) 235-4293
wglass (AT) forio (DOT) com
www.forio.com

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

+1

I especially agree with the removal of any exception handling where the
handling is to log the error. as my log files are not read nearly often
enough for this to work.

I wanted to talk a bit about the Uberspect & the Testable Uberspect.

I think it is a very good thing to develop with the Testable, since it will
catch mistakes in velocity simply and obviously.

which can really make development much less frustrating.

and for this reason, would wonder if it might be a good default, because
beginners( to anything) tend to get frustrated easily

That said, the LoggingUberspect (the current one) has obvious advantages in
Production because at that level you are not going to be there to fix
things, and if something goes wrong you don't want the page to be completely
gone because a small portion might not have been displayed right.

of course, i would argue, that by the time you reach production, you have
lost you beginner status :-)

llewellyn.

Message
From: "Will Glass-Husain" <wglass (AT) forio (DOT) com>
To: <velocity-dev (AT) jakarta (DOT) apache.org>
Sent: Monday, January 02, 2006 7:03 AM
Subject: RuntimeExceptions

First, happy new year to the Velocity developer community

I've been pondering how Velocity handles exceptions. Right now, almost every
call to a plugin has a catch-all Exception handler which does little more
than log the Exception. There's been a couple of requests in the past few
months to pass RuntimeExceptions or similar through.

* In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to pass
through a #parse. (we did this).
* Llewelyn Falco created a "TestableUberspect" which interrupted processing
upon an invalid method call.
* There was someone else (can't find the reference) who wanted to interrupt
processing when confronted with an invalid method call.

I was wondering, why does Velocity intercept every exception? Isn't the
point of a RuntimeException that it signals an application-level problem
that should be returned to the calling code? In addition, we should allow
plugins (event handlers, uberspectors, resource loaders) to interrupt
processing for critical problems. To me, there seems three choices.

(1) Catch every unexpected condition and do something with it (e.g. catch
NPE from toString() and wrap it in a MethodInvocationException). Logging
does not count as doing something.

(2) Create a special VelocityRuntimeException that plugins can use to
interrupt processing. Every generic catch (Exception E) wrapper would pass
this through. (I've coded this though not applied the patch).

(3) Remove all generic Exception catch's. (or if not feasible, always pass
RuntimeException's through).

To me, option #1 seems infeasible. (if we start wrapping toString, we'd
need to wrap a lot of other little stuff). #2 is useful for plugins
to interrupt processing. But I'm wondering, why not do option #3 and just
pass through all RuntimeExceptions. Any reason why we *should* be catching
unexpected RuntimeException's?

Appreciate other thoughts

Best,
WILL

Forio Business Simulations

Will Glass-Husain
phone (415) 440-7500 x89
mobile (415) 235-4293
wglass (AT) forio (DOT) com
www.forio.com

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

Llewellyn,

Thanks for the idea. I'm not sure changing the behavior from development to
production is a good idea for everyone. It's confusing. Also, the
distinction is not always so clear. In my app the production server
includes pages that are frequently changed by the user (e.g. those pages are
essentially in development).

But I would like to make this approach more prominent for beginners. Right
now it's pretty obscure. Maybe you'd be interested in writing a short
(couple paragraph) tutorial on the Wiki on how to use the TestableUberspect?

WILL

Message
From: "Llewellyn Falco" <isidore (AT) setgame (DOT) com>
To: "Velocity Developers List" <velocity-dev (AT) jakarta (DOT) apache.org>
Sent: Tuesday, January 03, 2006 8:53 AM
Subject: Re: RuntimeExceptions

+1
>
>
>
I especially agree with the removal of any exception handling where the
handling is to log the error. as my log files are not read nearly often
enough for this to work.
>
>
>
>
>
>
>
I wanted to talk a bit about the Uberspect & the Testable Uberspect.

I think it is a very good thing to develop with the Testable, since it
will catch mistakes in velocity simply and obviously.

which can really make development much less frustrating.
>
>
>
and for this reason, would wonder if it might be a good default, because
beginners( to anything) tend to get frustrated easily
>
>
>
>
>
That said, the LoggingUberspect (the current one) has obvious advantages
in Production because at that level you are not going to be there to fix
things, and if something goes wrong you don't want the page to be
completely gone because a small portion might not have been displayed
right.
>
>
>
of course, i would argue, that by the time you reach production, you have
lost you beginner status :-)
>
>
>
llewellyn.
>
>
>
>
>
Message
From: "Will Glass-Husain" <wglass (AT) forio (DOT) com>
To: <velocity-dev (AT) jakarta (DOT) apache.org>
Sent: Monday, January 02, 2006 7:03 AM
Subject: RuntimeExceptions
--
First, happy new year to the Velocity developer community

I've been pondering how Velocity handles exceptions. Right now, almost
every call to a plugin has a catch-all Exception handler which does little
more than log the Exception. There's been a couple of requests in the
past few months to pass RuntimeExceptions or similar through.

* In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to
pass through a #parse. (we did this).
* Llewelyn Falco created a "TestableUberspect" which interrupted
processing upon an invalid method call.
* There was someone else (can't find the reference) who wanted to
interrupt processing when confronted with an invalid method call.

I was wondering, why does Velocity intercept every exception? Isn't the
point of a RuntimeException that it signals an application-level problem
that should be returned to the calling code? In addition, we should allow
plugins (event handlers, uberspectors, resource loaders) to interrupt
processing for critical problems. To me, there seems three choices.

(1) Catch every unexpected condition and do something with it (e.g. catch
NPE from toString() and wrap it in a MethodInvocationException). Logging
does not count as doing something.

(2) Create a special VelocityRuntimeException that plugins can use to
interrupt processing. Every generic catch (Exception E) wrapper would
pass this through. (I've coded this though not applied the patch).

(3) Remove all generic Exception catch's. (or if not feasible, always
pass RuntimeException's through).

To me, option #1 seems infeasible. (if we start wrapping toString, we'd
need to wrap a lot of other little stuff). #2 is useful for
plugins to interrupt processing. But I'm wondering, why not do option #3
and just pass through all RuntimeExceptions. Any reason why we *should*
be catching unexpected RuntimeException's?

Appreciate other thoughts

Best,
WILL
>
>
>
>
>
>
>

Forio Business Simulations

Will Glass-Husain
phone (415) 440-7500 x89
mobile (415) 235-4293
wglass (AT) forio (DOT) com
www.forio.com

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

Thanks for the comments on RuntimeExceptions. I'll go ahead and apply this
to the source code.

I think it will simplify life for developers, in particular those writing
plugsins.

And as previously suggested in an earlier thread, for Velocity 2.0 I
definitely want to move to unchecked Exceptions exclusively.

WILL

Message
From: "Llewellyn Falco" <isidore (AT) setgame (DOT) com>
To: "Velocity Developers List" <velocity-dev (AT) jakarta (DOT) apache.org>
Sent: Tuesday, January 03, 2006 8:53 AM
Subject: Re: RuntimeExceptions

+1
>
>
>
I especially agree with the removal of any exception handling where the
handling is to log the error. as my log files are not read nearly often
enough for this to work.
>
>
>
>
>
>
>
I wanted to talk a bit about the Uberspect & the Testable Uberspect.

I think it is a very good thing to develop with the Testable, since it
will catch mistakes in velocity simply and obviously.

which can really make development much less frustrating.
>
>
>
and for this reason, would wonder if it might be a good default, because
beginners( to anything) tend to get frustrated easily
>
>
>
>
>
That said, the LoggingUberspect (the current one) has obvious advantages
in Production because at that level you are not going to be there to fix
things, and if something goes wrong you don't want the page to be
completely gone because a small portion might not have been displayed
right.
>
>
>
of course, i would argue, that by the time you reach production, you have
lost you beginner status :-)
>
>
>
llewellyn.
>
>
>
>
>
Message
From: "Will Glass-Husain" <wglass (AT) forio (DOT) com>
To: <velocity-dev (AT) jakarta (DOT) apache.org>
Sent: Monday, January 02, 2006 7:03 AM
Subject: RuntimeExceptions
--
First, happy new year to the Velocity developer community

I've been pondering how Velocity handles exceptions. Right now, almost
every call to a plugin has a catch-all Exception handler which does little
more than log the Exception. There's been a couple of requests in the
past few months to pass RuntimeExceptions or similar through.

* In Velocity-424, Malcolm Edgar wanted NPEs from a call to toString to
pass through a #parse. (we did this).
* Llewelyn Falco created a "TestableUberspect" which interrupted
processing upon an invalid method call.
* There was someone else (can't find the reference) who wanted to
interrupt processing when confronted with an invalid method call.

I was wondering, why does Velocity intercept every exception? Isn't the
point of a RuntimeException that it signals an application-level problem
that should be returned to the calling code? In addition, we should allow
plugins (event handlers, uberspectors, resource loaders) to interrupt
processing for critical problems. To me, there seems three choices.

(1) Catch every unexpected condition and do something with it (e.g. catch
NPE from toString() and wrap it in a MethodInvocationException). Logging
does not count as doing something.

(2) Create a special VelocityRuntimeException that plugins can use to
interrupt processing. Every generic catch (Exception E) wrapper would
pass this through. (I've coded this though not applied the patch).

(3) Remove all generic Exception catch's. (or if not feasible, always
pass RuntimeException's through).

To me, option #1 seems infeasible. (if we start wrapping toString, we'd
need to wrap a lot of other little stuff). #2 is useful for
plugins to interrupt processing. But I'm wondering, why not do option #3
and just pass through all RuntimeExceptions. Any reason why we *should*
be catching unexpected RuntimeException's?

Appreciate other thoughts

Best,
WILL
>
>
>
>
>
>
>

Forio Business Simulations

Will Glass-Husain
phone (415) 440-7500 x89
mobile (415) 235-4293
wglass (AT) forio (DOT) com
www.forio.com

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: velocity-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: velocity-dev-help (AT) jakarta (DOT) apache.org