This sounds like it might be a good basis for figuring out a parallel v3 API for a “hard to mis-use” style API. However, once you go that route, you start to wonder how useful templated log messages are when you can capture a lambda instead. Parameterized log messages might work better as structured log messages, something that is awkward to use in the API at the moment. — Matt Sicker
> On Nov 21, 2023, at 08:16, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi, > > Profiting from release 3.x we could slightly change the interpretation > of throwable parameters used in logging methods. > > IIRC in one of our online meetings, we raised the issue of logging > statements like this: > > logger.info("Error nr {}: {}", nr, throwable); > > which is not considered best practice and is probably not what the > user intended: > > logger.info("Error nr {}: {}", nr, throwable.getMessage(), throwable); > > A similar problem was reported in PR #1050[2]. > > Regarding this kind of statements, the OSGi Log[1] Service provides a > very nice alternative interpretation on how to deal with throwable > parameters: > > "If the last argument is a Throwable or a ServiceReference, it is > added to the generated LogEntry and then, if the next to last argument > is a ServiceReference or Throwable and not the same type as the last > argument, it is also added to the generated LogEntry. These arguments > will not be used as message arguments." > > Should we adopt a similar interpretation in 3.x? The advantages I see are: > > 1. We fix some inconsistencies in the API: > * we have a pair `info(String, Throwable)/info(String, Object)` > methods that prevents users from mistakenly pass a `Throwable` as a > log message argument, > * we only have `info(Object)`, > * we only have `info(String, Object, Object)`. > 2. We simplify our logic: right now we need logic to deal with > throwables in `Message`. On the other hand throwables are not > considered part of a message by any layout and are also included > separately in LogEvent. If we don't need to chase throwables in > parameterized messages, we don't need to parse the format string until > it is required. > 3. There might be some cases when including throwables in a log > message leads to information disclosure (e.g. when a user sees a log > message, but not the attached throwable). This way we'll have an API > which is easy to use and hard to misuse. > > Piotr > > [1] > https://docs.osgi.org/javadoc/osgi.core/8.0.0/org/osgi/service/log/Logger.html > [2] https://github.com/apache/logging-log4j2/pull/1050