[slf4j-dev] [Bug 70] " logging a stack trace along with a parameterized string" solution proposal

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=70


Thorbjørn Ravn Andersen <ravn at runjva.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ravn at runjva.com




--- Comment #10 from Thorbjørn Ravn Andersen <ravn at runjva.com>  2008-09-14 15:19:05 ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #4)
> > > Considering that message formatting is just a trick to improve performance,
> > > there is no real performance loss in writing:
> > > 
> > > } catch(Exception e) {
> > >  logger.error("Problem saying hello to " + name, e); 
> > > }
> > > 
> > > instead of 
> > > 
> > > } catch(Exception e) {
> > >  logger.error("Problem saying hello to {}", name, e); 
> > > }
> > 
> > I think its more about writability and readability of the code:
> > 
> > } catch(Exception e) {
> >     log.error("No row with id '{}' found", e, id);
> > }
> > 
> > } catch(Exception e) {
> >     log.error("No row with id '" + id + "' found", e, id);
> > }
> > 
> 
> Should the above code look like this
> 
> } catch(Exception e) {
>     log.error("No row with id '{}' found", id, e);
> }
> 
> } catch(Exception e) {
>     log.error("No row with id '" + id + "' found", e);
> }
> 
> or are you suggesting that the Exception should be put before the parameters? I
> wouldn't like that at all, especially because I know people expect it the other
> way around...
> 

Ceki brought my attention to the debate here in
http://www.qos.ch/pipermail/logback-user/2008-September/000579.html

The basic problem here as I see it is that we have a traditional log4j approach
of logging a string with an optional exception tagged at the end, which has
then be found to work strangely with the Javac 1.5 varargs construction which
has been introduced to work nicely with the {} construction.

If we keep using varargs it will not work without having to analyze the runtime
types of the passed arguments _somewhere_ at runtime instead of letting the
java compiler sort this out at compile time.  I don't like that.

Instead I suggest dumping varargs in the slf4j layer altogether and simply
create the many methods for having up to X arguments with and without an
exception.  Currently X is two (these kind of things you learn when you work in
1.4 world) which is a bit low.  I suggest raising X to e.g. 5 which covers most
cases I have met.  If you need more than that you must create an Object[]
yourself.


-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.