[smila-dev] RE: convention in logging exceptions

[Sebastian Voigt <svoigt@xxxxxxx>]

Log and throw makes only sense in a client-server architecture.
We have no clients except Jconsole and the JmxAgent, and these clients use JMX for the commmuncation,
thus Exceptions are not "forwarded".

I think we should use the Rule: 
Never log and throw.
Because the "process" that catches the exception is responsible for logging.

Sebastian

> -----Original Message-----
> From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Menzel
> Sent: Friday, October 17, 2008 12:21 PM
> To: Smila project developer mailing list
> Subject: [smila-dev] convention in logging exceptions
> 
> hi all,
> 
> i have had no feedback on this so far.
> if nobody objects I will add this to the convention page!
> 
> Kind regards
> Thomas Menzel @ brox IT-Solutions GmbH
> 
> 
> -----Original Message-----
> From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Menzel
> Sent: Dienstag, 30. September 2008 11:01
> To: Smila project developer mailing list
> Subject: RE: [smila-dev] RE: Current Logging Settings
> 
> hi daniel,
> 
> thx for ur input but i have some remark to:
> 
> /////////////
> *  log exceptions before throwing new exceptions, e.g.
> 
> ...
> if( paramXY == null ) {
>     if (_log.isErrorEnabled()) {
>         _log.error("paramXY is not set");
>     }
>     throw new NullPointerException("paramXY is not set"); } ////
> 
> 
> I advise against this as it only causes the same message to be repeated at least twice, namely when the
> exception is created and then when the exception is logged itself.
> IMO it is sufficient to have a verbose error msg and this then is reported along with the stack trace when
> the exception is logged.
> if the exception is handled then this message is even confusing b/c u have ERROR log entry but wonder: what
> happened then?
> if u deem the condition so extraordinary and dangerous we could log it as warning, but since we don’t log the
> eception here it should not be level ERROR.
> 
> even worse than this is sometimes the habit to log an exception before (re)throwing or wrapping it, which I
> have seen as often (in general, not this project in particular).
> this then has the effect that u have the same exception logged several times which makes the log very verbose
> and confusing. as u think u have lot of problems/exception when it fact it is only that one case.
> 
> of course this only applies when u remain within our own system bounds. if u write a libray that is called
> from other code then it is wise to log the exception at ur system boundery, i.e. the method that was called
> by the client, that might not adhere to sound loging standards.
> again, there are also pitfalls with this convention, e.g. in case of an overloaded API method where u have a
> simple version that delegates to a more verbose other API method that also could be called from a client.
> 
> Kind regards
> Thomas Menzel @ brox IT-Solutions GmbH
> 
> 
> -----Original Message-----
> From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Daniel.Stucky@xxxxxxxxxxx
> Sent: Montag, 29. September 2008 14:36
> To: smila-dev@xxxxxxxxxxx
> Subject: AW: [smila-dev] RE: Current Logging Settings
> 
> Hi all,
> 
> I added a section "Logging guidelines" to our Development_Guidelines:
> http://wiki.eclipse.org/SMILA/Development_Guidelines#Logging_guidelines
> Feel free to comment or improve.
> 
> I ask all to share their thoughts about how to fill the table "When to use what log level and what
> information to provide?"
> Especially those who have trouble finding the "real" errors :-)
> 
> Bye,
> Daniel