IMHO 2 traces in the log are better than 0 - the important thing is that you have something you can look at when debugging. It is of course important that the business object still throws the exception even if it logged it (which is indeed what you are doing). (Ive had the misfortune to have to use objects developed by a third party that log (often to System.out!!!!) exceptions they generate and then dont throw an exception back at my code - just return a null or something equally useless. Its a real pain I can tell you...)
Of course components using your object will (should!) probably want to throw their own exceptions too that nest that thrown by the object as they will want to record information about their state and what they were doing when the thrown excrements trajectory caused it to collide with their rotary atmospheric impeller... (And thats info that the business object won't have but that you will also want for debugging) -----Original Message----- From: RODRIGO CARVALHO DOS SANTOS [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 20:56 To: 'Struts Users Mailing List' Subject: [Struts Tip] #15 Use chained exceptions. Design consideration. Hi Ted and all in the list, I�m using ChainedExceptions in my applications, but in my case the Business Object is using the logger from Log4J. When an exception occurs, the Business Object logs a message before throwing a new exception with the original exception chained. I think this is important for application traceability, the object does not depend on others layers to log his own problems. If my Business Object is a component, maybe the component user will log the stack trace, having some redundancy of information. I would like to hear from the group opnions about this design approach. Rodrigo Santos. Brazil. BCP Telecomunica��es. -----Mensagem original----- De: Ted Husted [mailto:[EMAIL PROTECTED]] Enviada em: domingo, 17 de novembro de 2002 22:47 Para: [EMAIL PROTECTED] Assunto: [Struts Tip] #15 Use chained exceptions Many Java mavens recommend that business objects throw their own exceptions. Internally, a component may catching a SQL or IO exception, but what we really need to tell the user is that a data access error occurred. Of course, at the same time, you do not want to sacrifice any detail from the original exception. Retaining detail from the exception can especially important in a layered, multi-tiered, or multi-platform application.. The business component may not have direct access to the log, and the exception is its only way of telling us what went wrong. [more ... <http://husted.com/struts/tips/015.html>] -- 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
