Well, the pattern (I won't call it an anti-pattern) is to do something
like this:
public abstract class FooActionBase extends ActionSupport {
public doExecute() throws Exception {
try {
return process();
} catch(Exception blah) {
// maybe make a note of the error somewhere, of course
return ERROR;
}
}
public abstract String process() throws Exception;
}
Then, the actual exceptions use process() instead of doExecute() or
execute(). It's the same pattern that yields execute() and doExecute(),
except one level deeper and done at a later implementation level.
To me, that's framework-appropriate, to allow a callback to potentially
trap that error. That's why I brought it up. As far as the specific names,
well, yeah, I can see an issue with that. :)
The fact that you implemented this behaviour - as did I, as is the client
who mentioned this to me - makes it sound like it's something common
enough to be normalizable.
On Mon, 3 Nov 2003, James Cook wrote:
> > -----Original Message-----
> > Behalf Of Joseph Ottinger
> > What I'd thought of was adding an extra method to Action and
> > ActionSupport. The Action method's signature might look like this:
> > ...
> > Thoughts? Insults? Points?
>
> I thought of a pointless insult. ;-)
>
> We used this pattern in a large application and it worked well. BTW, for
> Hani's edification
> (http://www.jroller.com/page/fate/20031029#opensymphony_dirty_laundry),
> this is not a toy application, but rather a large app that manages
> billions of dollars per year for a State entity.
>
> I don't have an opinion as to whether it should be added to
> ActionSupport, but I'm curious as to where people think the line should
> be drawn. Why should this be added to ActionSupport as opposed to your
> own subclass? (We all have subclassed ActionSupport or rolled our own,
> haven't we?)
>
> BTW, not a major issue (for us), but it would break our subclass of
> ActionSupport that throws a more specific exception.
>
> protected String handleException(Throwable t) throws
> ApplicationException;
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
-------------------------------------------------------------------
Joseph B. Ottinger http://enigmastation.com
IT Consultant [EMAIL PROTECTED]
J2EE Editor - Java Developer's Journal [EMAIL PROTECTED]
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
