Re: [EXCEPTION HANDLING] Handing bean errors in Action class (per Struts Users Guide)

[Eddie Bush <ek...@swbell.net>]

Charlie Toohey wrote:

>The Struts User's Guide advocates the following (section 4.2), with respect 
>to how exceptions/errors in beans called by Action classes should be handled 
>by the Action class :
>
>"The beans that represent the Model of your system may throw exceptions due 
>to problems accessing databases or other resources. You should trap all such 
>exceptions in the logic of your perform() method, and record them in the 
>application's log (along with the corresponding stack trace) by calling:
>     servlet.log("Error message text", exception); "
>
Sounds like it hasn't been updated for 1.1.  The "1.1 way of doing 
things" involves execute(...) throws Exception -- so you can use the 
error-handling in Struts 1.1.

>This seems very odd to me. I would expect to write a bean that fully 
>encapsulates all database activity, including all exception handling, closing 
>statements, result sets, connections, etc. before returning to the Action 
>perform method. But the Struts Users Guide is advocating handling exceptions 
>from the bean in the Action perform method --- which means that the Action 
>class perform method would include database code, which is clearly 
>undesireable, from the perspective of a reusable bean and separation of 
>roles.  Or , am I wrong here ??
>
I think what's being talked about are the "Application exceptions" you 
would write that would give a clearer picture to the user about what 
happened.  Yes, your beans should handle the exceptions they can, and 
wrap any they can't in "higher-level exceptions" which would be thrown. 
 I think this is the generally-accepted approach.  It's how I do things.

>It would seem to me that the best way to maintain a separation between the 
>Struts Action and the database code would be to have bean methods which 
>handle all exceptions within the bean and then return a result code, rather 
>than throwing unhandled exceptions.
>
I suppose you could do that too.  By throwing a "custom" exception, 
you're able to "send a message up through the layers" that something 
went wrong.  You could, in 1.1, either catch all exceptions and do your 
own thing to communicate to the user what happened, or use Struts' 
declarative error-handling to do this.  The choice is yours.  I'm not 
aware of what the "best practice" is, but I strongly suspicion that 
using the struts error mechanism is.

>Any comments ?
>
Hopefull there will be additional banter.  I think this is a worthy topic.

Regards,

Eddie



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>