A problem with the lacking "exception" interface

[Matt Quigley-2]

I just wanted to suggest something, given that I have a problem with
the given interface. To log an exception with SLF4J, we have:

 public void debug(String msg, Throwable t);

There is no "debug(Throwable t);" for reasons given at
http://www.slf4j.org/faq.html#exception_message. However, what is
given is a series of arguments telling me I don't know what I'm doing.

I completely agree that a message should be given with exceptions,
what I disagree with is that you have to pass in a String to do so.
Not all exceptions are NullPointerExceptions, mind you. There is
absolutely no reason I should have to pass a message to the logger
with the following:

try {
   ...
   throw new MyCustomException("Table not found in the database", tableName);
} catch (MyCustomException e) {
   log.warn("Table not found in the database", e);
}

Given that there is enough information in the exception to log an
error appropriately, why is it that the interface forces me to do it
the "good way (TM)"?  I mean, does adding that extra interface method
really screw things up?  Will it slow things down?  Will it make users
code clunky?  Is it SLF4J's way of making sure everyone is a good
programmer? (I have a feeling that's the answer) One thing it
certainly does is clutter up certain parts of my code unnecessarily.
I can think of a few more reasons why I disagree with this.  Shouldn't
the library be usable in all scenarios?  It's removing functionality
that is already inherently in the library anyways!  The arguments say
that removing this functionality is a good thing (TM), but I couldn't
disagree more.

I just thought that since you guys put a lot of thought into the
interface, I'd tell you how it's affected me in my experiences of
converting many of my company's projects from log4j to SLF4J.  BTW, I
like SLF4J a lot better!

-Matt
_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user

[Ceki Gulcu-2]

Hello Matt,

Comments inline.

Matt Quigley wrote:
> I just wanted to suggest something, given that I have a problem with
> the given interface. To log an exception with SLF4J, we have:
>
>  public void debug(String msg, Throwable t);
>
> There is no "debug(Throwable t);" for reasons given at
> http://www.slf4j.org/faq.html#exception_message. However, what is
> given is a series of arguments telling me I don't know what I'm doing.

The arguments presented in [1] are imho objective and relevant to the
topic. I don't see any allusions to the personal qualities of the
reader/slf4j user, neither in substance nor tone.  I can understand why
you may not agree with the arguments but don't see how one could take
them personally. What makes you think that the arguments given are "a
series of arguments telling [you] don't know what [you are] doing"?

> I completely agree that a message should be given with exceptions,
> what I disagree with is that you have to pass in a String to do so.

OK.

> Not all exceptions are NullPointerExceptions, mind you. There is
> absolutely no reason I should have to pass a message to the logger
> with the following:
>
> try {
>    ...
>    throw new MyCustomException("Table not found in the database", tableName);
> } catch (MyCustomException e) {
>    log.warn("Table not found in the database", e);
> }

Yes.

> Given that there is enough information in the exception to log an
> error appropriately, why is it that the interface forces me to do it
> the "good way (TM)"?  I mean, does adding that extra interface method
> really screw things up?  Will it slow things down?  Will it make users
> code clunky?  Is it SLF4J's way of making sure everyone is a good
> programmer? (I have a feeling that's the answer) One thing it
> certainly does is clutter up certain parts of my code unnecessarily.
> I can think of a few more reasons why I disagree with this.  Shouldn't
> the library be usable in all scenarios?  It's removing functionality
> that is already inherently in the library anyways!  The arguments say
> that removing this functionality is a good thing (TM), but I couldn't
> disagree more.

In the last paragraph of [1], "good thing (TM)" is meant humorously,
mostly in self-derision. All log4j-derived systems have aligned
themselves with log4j's requirements about logging exceptions --
that's just the way it is. Of course, saying "that's just the way it
is", is a pretty weak argument, hence the need for a like joke with a
reference to "good thing (TM)".

> I just thought that since you guys put a lot of thought into the
> interface, I'd tell you how it's affected me in my experiences of
> converting many of my company's projects from log4j to SLF4J.  BTW, I
> like SLF4J a lot better!

Thank you.

Users have been complaining about this issue for a long time. It's one
of log4j's, and by association, slf4j's, warts. Keep in mind that at
one point, slf4j, which was called "ugli" at the time, was supposed to
be 100% compatible with log4j. To make a long story short, 100%
compatibility is gone but the wart stayed. Now that SLF4J has a large
user base, we can't touch the slf4j API.


> -Matt

[1] http://www.slf4j.org/faq.html#exception_message

--
Ceki Gülcü

QOS.ch is looking to hire talented developers located in Switzerland
to work on cutting-edge software projects. If you think you are
qualified, then please contact ceki@....
_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user

[Matt Quigley-2]

> Matt Quigley wrote:
>> I just wanted to suggest something, given that I have a problem with
>> the given interface. To log an exception with SLF4J, we have:
>>
>>  public void debug(String msg, Throwable t);
>>
>> There is no "debug(Throwable t);" for reasons given at
>> http://www.slf4j.org/faq.html#exception_message. However, what is
>> given is a series of arguments telling me I don't know what I'm doing.
>
> The arguments presented in [1] are imho objective and relevant to the
> topic. I don't see any allusions to the personal qualities of the
> reader/slf4j user, neither in substance nor tone.  I can understand why
> you may not agree with the arguments but don't see how one could take
> them personally. What makes you think that the arguments given are "a
> series of arguments telling [you] don't know what [you are] doing"?

I was not taking them personally. My point is that the argument says
that "this is the way we think it should be done, logging exceptions
should be accompanied by a contextual message, so you have to do it
this way with our interface, and we don't trust you to do it another
way."  Not necessarily me personally, but I feel that myself or other
people who write good code are being forced to conform to the common
denominator by this argument.

>> I completely agree that a message should be given with exceptions,
>> what I disagree with is that you have to pass in a String to do so.
>
> OK.
>
>> Not all exceptions are NullPointerExceptions, mind you. There is
>> absolutely no reason I should have to pass a message to the logger
>> with the following:
>>
>> try {
>>    ...
>>    throw new MyCustomException("Table not found in the database", tableName);
>> } catch (MyCustomException e) {
>>    log.warn("Table not found in the database", e);
>> }
>
> Yes.

This is my main point.  I think programs that make use of elegant
exception handling are punished by making sure all logged exceptions
require a pertinent explanation, when that explanation already exists
in either/both the exception's description and the stack trace.
Again, the lowest common denominator problem.  If users don't write
good code in the first place, SLF4J's interface isn't going to change
that ;).

>
>> Given that there is enough information in the exception to log an
>> error appropriately, why is it that the interface forces me to do it
>> the "good way (TM)"?  I mean, does adding that extra interface method
>> really screw things up?  Will it slow things down?  Will it make users
>> code clunky?  Is it SLF4J's way of making sure everyone is a good
>> programmer? (I have a feeling that's the answer) One thing it
>> certainly does is clutter up certain parts of my code unnecessarily.
>> I can think of a few more reasons why I disagree with this.  Shouldn't
>> the library be usable in all scenarios?  It's removing functionality
>> that is already inherently in the library anyways!  The arguments say
>> that removing this functionality is a good thing (TM), but I couldn't
>> disagree more.
>
>
> In the last paragraph of [1], "good thing (TM)" is meant humorously,
> mostly in self-derision. All log4j-derived systems have aligned
> themselves with log4j's requirements about logging exceptions --
> that's just the way it is. Of course, saying "that's just the way it
> is", is a pretty weak argument, hence the need for a like joke with a
> reference to "good thing (TM)".

I took the joke humorously, and was turning it on itself considering I
don't think it's a good thing.

>> I just thought that since you guys put a lot of thought into the
>> interface, I'd tell you how it's affected me in my experiences of
>> converting many of my company's projects from log4j to SLF4J.  BTW, I
>> like SLF4J a lot better!
>
> Thank you.
>
> Users have been complaining about this issue for a long time. It's one
> of log4j's, and by association, slf4j's, warts. Keep in mind that at
> one point, slf4j, which was called "ugli" at the time, was supposed to
> be 100% compatible with log4j. To make a long story short, 100%
> compatibility is gone but the wart stayed. Now that SLF4J has a large
> user base, we can't touch the slf4j API.

That's a shame.  Although I know it's a pain for those who implement
library interfaces to have to update to a new interface, it does
happen as time goes on (for example, I've had to upgrade many projects
from log4j to slf4j).  This is an instance that wouldn't require
_that_ much pain, as I can only imagine how quickly and easily this
particular new interface method requirement would be met... copy the
same methods, but just don't log a message string, only the stack
trace.

Anyways, it's something to keep in mind for next time, I figured since
TRACE was reimplemented it wouldn't hurt to throw my two cents in
there.  As many readers can attest to, code style is an art of form
and functionality, and being forced to conform to (in the artist's
opinion) an inferior style can be repugnant.

-Matt
_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user

[Rusty Wright-2]

I'm not sure if this is what you're talking about but here's what I use for logging exceptions:

http://commons.apache.org/lang/api-release/org/apache/commons/lang/exception/ExceptionUtils.html#getFullStackTrace(java.lang.Throwable)

For example:

        try {
            results = directorySearch.getByGivenNameSurname(searchCriteria);
        }
        catch (final LimitExceededException e) {
            log.error("limit exceeded exception: {}", ExceptionUtils.getStackTrace(e));
        }


Matt Quigley wrote:

Matt Quigley wrote:
    

I just wanted to suggest something, given that I have a problem with
the given interface. To log an exception with SLF4J, we have:

 public void debug(String msg, Throwable t);

There is no "debug(Throwable t);" for reasons given at
http://www.slf4j.org/faq.html#exception_message. However, what is
given is a series of arguments telling me I don't know what I'm doing.
      

The arguments presented in [1] are imho objective and relevant to the
topic. I don't see any allusions to the personal qualities of the
reader/slf4j user, neither in substance nor tone.  I can understand why
you may not agree with the arguments but don't see how one could take
them personally. What makes you think that the arguments given are "a
series of arguments telling [you] don't know what [you are] doing"?
    

I was not taking them personally. My point is that the argument says
that "this is the way we think it should be done, logging exceptions
should be accompanied by a contextual message, so you have to do it
this way with our interface, and we don't trust you to do it another
way."  Not necessarily me personally, but I feel that myself or other
people who write good code are being forced to conform to the common
denominator by this argument.

  

I completely agree that a message should be given with exceptions,
what I disagree with is that you have to pass in a String to do so.
      

OK.

    

Not all exceptions are NullPointerExceptions, mind you. There is
absolutely no reason I should have to pass a message to the logger
with the following:

try {
   ...
   throw new MyCustomException("Table not found in the database", tableName);
} catch (MyCustomException e) {
   log.warn("Table not found in the database", e);
}
      

Yes.
    

This is my main point.  I think programs that make use of elegant
exception handling are punished by making sure all logged exceptions
require a pertinent explanation, when that explanation already exists
in either/both the exception's description and the stack trace.
Again, the lowest common denominator problem.  If users don't write
good code in the first place, SLF4J's interface isn't going to change
that ;).

  

Given that there is enough information in the exception to log an
error appropriately, why is it that the interface forces me to do it
the "good way (TM)"?  I mean, does adding that extra interface method
really screw things up?  Will it slow things down?  Will it make users
code clunky?  Is it SLF4J's way of making sure everyone is a good
programmer? (I have a feeling that's the answer) One thing it
certainly does is clutter up certain parts of my code unnecessarily.
I can think of a few more reasons why I disagree with this.  Shouldn't
the library be usable in all scenarios?  It's removing functionality
that is already inherently in the library anyways!  The arguments say
that removing this functionality is a good thing (TM), but I couldn't
disagree more.
      

In the last paragraph of [1], "good thing (TM)" is meant humorously,
mostly in self-derision. All log4j-derived systems have aligned
themselves with log4j's requirements about logging exceptions --
that's just the way it is. Of course, saying "that's just the way it
is", is a pretty weak argument, hence the need for a like joke with a
reference to "good thing (TM)".
    

I took the joke humorously, and was turning it on itself considering I
don't think it's a good thing.

  

I just thought that since you guys put a lot of thought into the
interface, I'd tell you how it's affected me in my experiences of
converting many of my company's projects from log4j to SLF4J.  BTW, I
like SLF4J a lot better!
      

Thank you.

Users have been complaining about this issue for a long time. It's one
of log4j's, and by association, slf4j's, warts. Keep in mind that at
one point, slf4j, which was called "ugli" at the time, was supposed to
be 100% compatible with log4j. To make a long story short, 100%
compatibility is gone but the wart stayed. Now that SLF4J has a large
user base, we can't touch the slf4j API.
    

That's a shame.  Although I know it's a pain for those who implement
library interfaces to have to update to a new interface, it does
happen as time goes on (for example, I've had to upgrade many projects
from log4j to slf4j).  This is an instance that wouldn't require
_that_ much pain, as I can only imagine how quickly and easily this
particular new interface method requirement would be met... copy the
same methods, but just don't log a message string, only the stack
trace.

Anyways, it's something to keep in mind for next time, I figured since
TRACE was reimplemented it wouldn't hurt to throw my two cents in
there.  As many readers can attest to, code style is an art of form
and functionality, and being forced to conform to (in the artist's
opinion) an inferior style can be repugnant.

-Matt
_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user
  

_______________________________________________
user mailing list
user@...
http://www.slf4j.org/mailman/listinfo/user