We also follow the second approach, and propagate all the exceptions from the business beans to the action classes. However, since our business beans don't know about the application they are in, we are finding that their error messages are not the worlds best. Has anyone come up with a good solution for this?
-- Larry Maturo [EMAIL PROTECTED] -----Original Message----- From: Jerome Josephraj [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 10:07 AM To: Struts Users Mailing List Subject: RE: exception handling in business beans Adolfo, We have similar architecture and we follow the second approach. We propagate all the exceptions from the business bean to action class and log it in there (infact in ActionClass facade which delegates all the requests to appropriate action classes). By doing this way any changes in log4j/additional functionality (i.e firing a mail)/any niceties can be added at one place Cheers, Jerome. -----Original Message----- From: Adolfo Miguelez [mailto:[EMAIL PROTECTED]] Sent: 09 April 2002 15:35 To: [EMAIL PROTECTED] Subject: exception handling in business beans Hi All, just a design question, probably beyond Struts scope, but interesting anyway. As the documentation says, business beans, invoked from Action classes must atomically handle access to resources. They should not even know that they are running in a web application, so they be reusable pieces. My question is about opinions about handling exceptions. We intend use Log4J proyect for this task. I figure out two possible approaches: 1- handling exceptions try{}catch{} in each single business bean and logging to log files from them, or 2- propagate such exceptions to the invoker Action which will be responsible for logging and doing right treatment. For this solution, classes that propagate the exceptions upwards should add their identification to the message or whichever info necessary for identiying the exception source. I bet for second approach, since IMHO it produces reusable beans, untied to log configuration. I would appreciate opinions for this concern. Regards, Adolfo. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> _____ This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
