Logging with last implicit param a null Throwable generates framework warning

[dainiusvaznys]

Description

Issue #2380 introduces generation of framework warning when last (implicit) parameter is a null Throwable.

Configuration

Version: 2.25.1

Operating system: Windows 11

JDK: Java HotSpot(TM) 64-Bit Server VM (build 25.461-b11, mixed mode)

Logs

2025-10-30T13:17:14,249 ERROR [main] MyTest {} - Execution completed with result invalid
java.lang.RuntimeException: failed
	at ...

2025-10-30T11:17:14.252438500Z main WARN found 1 argument placeholders, but provided 2 for pattern `Execution completed with result {}`
2025-10-30T13:17:14,251 ERROR [main] MyTest  {} - Execution completed with result valid

Reproduction

Some libraries provide execution results in an 'Either' style of structure (e.g. dev.failsafe.event.ExecutionCompletedEvent) --result or an exception. Such cases could conveniently be logged like

logger.error("Execution completed with result {}", outcome.result, outcome.failed);

That is, if we have failure Throwable -- log its stack trace. But if it is null and the error is described in .result -- just log what we have. This used to work properly until a fix for #2380 introduces a warning (WARN found 1 argument placeholders, but provided 2 for pattern), see sample test below and its output above.

  record Result(
          String result,
          Throwable failed
  ) {}

  @Test
  void testLog4j() {
    var logger = org.apache.logging.log4j.LogManager.getLogger(MyTest.class);
    var failedResult = new Result("invalid", new RuntimeException("failed"));
    logger.error("Execution completed with result {}", failedResult.result, failedResult.failed);

    var validResult = new Result("valid", null);
    logger.error("Execution completed with result {}", validResult.result, validResult.failed);
  }

[lrozenblyum]

Yes, it would be good to fix that. Now we have to work around it by checking the throwable for null and having 2 log.error statements in if/else

[ppkarwasz]

Hi @dainiusvaznys,

Sorry, I must have missed this report.

As you noted, the problems stems from the way the last parameter is checked for throwables:

logging-log4j2/log4j-api/src/main/java/org/apache/logging/log4j/message/ParameterFormatter.java

Lines 249 to 250 in 9c22ca2

	final int noThrowableArgCount =
	argCount < 1 ? 0 : argCount - ((args[argCount - 1] instanceof Throwable) ? 1 : 0);

Since null instanceof Throwable gives false, noThrowableArgCount has the wrong value. Feel free to submit a PR that fixes it together with a small regression test.

[lrozenblyum]

@ppkarwasz @dainiusvaznys I may start working on this

[ppkarwasz]

Hi @lrozenblyum, thanks!