Re: [Actionframework-users] patch to AFWException.java

[Mark D. A. <md...@di...>]

> I wouldn't name the method getStackTrace() because there is such a
> method in JDK 1.4. The question is whether to introduce, say
> getStackTraceString(), or let people migrate to 1.4.

Yes, getStackTrace() was a bad choice as a name.

Another problem with using my idea of $error.StackTrace is that it would only work with
exceptions that have that method, and rather I'd like all exceptions to work.
Also, it doesn't deal with html parameter escaping.

So now I'm thinking that AFWException.java should not be touched.
And my error.vm will use a tool like "$Tools.getErrorMessage($error)"

I would suggest however that the AS core code be changed to help bind
exception objects. That way the policy of what to display is not restricted by the core.

One approach would be to bind the "error" context variable to an exception
object instead of a string. This will generally work since "$error" would call
its toString method (which however should be escaped).

Another approach would be to separately bind an "exception" context variable
before invoking error.vm (in addition to any "error").

Other related suggested changes:
- change onException() to accept any Throwable, not just ActionException
- change Template error(Context context, String message) to Template error(Context context, String message, Throwable e)
where e might be null. You might pass in a boolean too, such as "boolean already_escaped" to indicate
whether the string might already have had html entity escaping done.
[i'd also suggest renaming the error() method to onErrorMessage() or getErrorTemplate or something]

>  > There still seem to be a whole bunch of different exceptions that are
>  > not caught by onException, which is a different problem....
> 
> ConversionExceptions are not, others should be. Do you have an example?

I'm sorry I didn't keep good records. When I first started using AS, it seemed
almost nothing was caught by AS, because my errors were so fundamental.
Now it is catching more.

But just looking at the code, it is clear how things can get through:
1. handle() does significant work outside of a try clause, and only catches IOException
2. processRequest() only catches Exception, not Throwable.
Since the fallback handling is terrible, I always have servlet handlers catch Throwable.
Particularly if you are going to Method.invoke, which can spew all sorts of non-Exception objects.

-mda