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

[Petr T. <Pet...@pi...>]

 > 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").

AS is designed so that onException() should be called for all exceptions
(unhandled by <on-exception> elements) -> you can override onException()
and put anything you like to context.

I think that binding "exception" is better than changing "error" type to
Exception, since there could be errors not caused by exception.

I usually override onException() and for unexpected exceptions do:

    ByteArrayOutputStream out = new ByteArrayOutputStream();
    StringBuffer sb = new StringBuffer(e.toString() + "<P><PRE>");
    e.printStackTrace(new PrintStream(out));
    sb.append(out.toString() + "</PRE>");
    return error(context, sb.toString());

 > 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)

onException() is passed ActionException which (usually) holds exception
origin - "detail" field, so you can always do wrapping, but I don't see
any objection for widening ActionException to Throwable :)

error() method serves only as provider of a default error page and you
can put anything to context - why do you want the Throwable parameter?
To keep backward compatibility, error(*whatever*) had to be added, not
changed.

 > 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.

Ok, I will review the code and put Throwable where possible :)

Petr

PS: I will reply to the rest of your questions tomorrow.
-- 
[ http://dione.zcu.cz/~toman40 - Pet...@pi... - ICQ=22957959 ]