[slf4j-user] When more parameters than placeholders, extra parameters are not logged

[Ceki Gulcu]

Hi Erik,

Thank you for your message. In this case, Ross cross posted on slf4j-dev 
and I has already provided an answer there. I repeat it here for the 
convenience of the reader.

Catering for the eventuality of extra parameters would be relatively 
complicated. More importantly, I think that it is not SLF4J's 
responsibility to fix every possible error that could be made by the 
programmer.

In addition, the fluent API allows adding key value pairs which should 
avoid the pitfall described by Ross.

Best regards,

-- 
Ceki Gülcü

Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

On 02/02/2025 08:47, Erik van Oosten via slf4j-user wrote:
> Hi Russ,
> 
> Mailing lists are not so popular anymore nowadays, chances that a sl4fj 
> developer will respond here are not so good. Probably the best thing to 
> do is write a feature request on https://github.com/qos-ch/slf4j/issues. 
> A pull request is probably be appreciated as well!
> 
> Kind regards,
>      Erik.
> 
> 
> Op 25-01-2025 om 02:38 schreef Russ Block via slf4j-user:
>> With this method or any similar method,
>>     public void info(String format, Object... arguments) {
>>         if (isInfoEnabled()) {
>>             handleArgArrayCall(Level.INFO, null, format, arguments);
>>         }
>>     }
>> If the number of objects in 'arguments' is more than the number of 
>> placeholders, {}, the extra argument objects are not logged.  Is there 
>> a reason for that?
>>
>> For example
>>   public void setTemperature(Integer temperature) {
>>     oldT = t;
>>     t = temperature;
>>   //Sent three parameters log with two placeholders
>>   //Output "Temperature set to 90. Old value was null." The word extra 
>> is not printed
>>     logger.info("Temperature set to {}. Old value was {}.", t, oldT, 
>> "extra");
>>     if(temperature.intValue() > 50) {
>>       logger.info("Temperature has risen above 50 degrees.");
>>     }
>>   }
>>
>>
>> If I get into a situation where I have sent more argument objects than 
>> placeholders that it should append those un-placed arguments to the 
>> end of the logged string.  The intent of the developer is to have the 
>> parameter logged. Finding this out from production is not good.  What 
>> is sent to be logged is important information, depending on the log level.
>>
>> My use case is that I want to push some legacy code to start looking 
>> like SLF4J so we can migrate away from the older pattern filled with 
>> isLogTraceEnabled calls.  I learned of the above when I was writing 
>> JUnit tests to see all the things the code would do and not do.
>>
>> I feel that https://www.slf4j.org/faq.html#logging_performance is 
>> telling me that, in some way, the placeholder string substitution is 
>> faster than appending multiple strings together.  I understood the 
>> main point of the argument as converting items to string before I 
>> needed them was where the overhead was.  Keeping them as type Object 
>> reduces that overhead.
>>
>> I understand there are Sonarqube rules and PMD to prevent me from not 
>> having the correct number of argument objects.  This would help, but I 
>> feel like there are still going to be misses.  Since my code is 
>> custom, Sonarqube and PMD do not feel like options.
>>
>> _______________________________________________
>> slf4j-user mailing list
>> slf4j-user at qos.ch
>> https://mailman.qos.ch/cgi-bin/mailman/listinfo/slf4j-user
> 
> -- 
> Erik van Oosten
> e.vanoosten at grons.nl
> https://day-to-day-stuff.blogspot.com
> 
> 
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at qos.ch
> https://mailman.qos.ch/cgi-bin/mailman/listinfo/slf4j-user