Exception handling in Java is neat when we know what we are doing. However junior
developers often find themselves with exceptions that they aren't really expecting and
don't know what to do with. With no direction from others its all to easy to use
System.out and I have even seen:
catch(Exception e)
{
}
I think this is why the C# guys made their exceptions more like our runtime
exceptions. You don't have the explicit declaration of what exceptions are thrown but
it doesn't force inexperienced developers to end up writing stuff that we wouldn't
want them to do. All interesting stuff but not sure what it has to do with struts.
Quentin
-----Original Message-----
From: Andrew Hill [mailto:[EMAIL PROTECTED]]
Sent: 18 November 2002 12:04
To: Struts Users Mailing List
Subject: RE: [Struts Tip] #15 Use chained exceptions. Design
consideration.
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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
