How to ignore/mock Slf4j log lines?

I upgraded Spring Boot from 2.5.10 to 2.5.12 and it brought a breaking change for me in logback

A few of my unit tests (using Mockito) are breaking with NullPointerException where I am passing a mocked exception to the log lines in the main code. For example, this is a log line that I have in my main code, and the class is annotated with lombok's @Slf4j

log.warn("Exception occurred while doing something", exception);

Earlier, this log line was not throwing any errors.

My intention here is to not mock the logger, but to ignore this line through whatever workaround possible (even if I have to mock it).

Lombok adds the following on compilation (not sure if mocking would work here):

private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(HelloWorld.class);

One workaround I have is to not use mocked exceptions and pass an actual exception but that's going to take the fun out of unit tests.

Stack trace:

    at ch.qos.logback.classic.spi.ThrowableProxy.<init>(
    at ch.qos.logback.classic.spi.ThrowableProxy.<init>(
    at ch.qos.logback.classic.spi.LoggingEvent.<init>(
    at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(
    at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(
    at ch.qos.logback.classic.Logger.warn(
    at com.example.r.e.d.s.d.t.HelloWorld.executeInternal(
    at com.example.r.e.d.s.d.t.HelloWorldTest.testLocksOnDomain(
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(
    at java.base/java.lang.reflect.Method.invoke(
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(
    at org.junit.internal.runners.statements.RunBefores.evaluate(
    at org.mockito.internal.runners.DefaultInternalRunner$1$1.evaluate(
    at org.junit.runners.ParentRunner$3.evaluate(
    at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(
    at org.junit.runners.ParentRunner.runLeaf(
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(
    at org.junit.runners.ParentRunner$
    at org.junit.runners.ParentRunner$1.schedule(
    at org.junit.runners.ParentRunner.runChildren(
    at org.junit.runners.ParentRunner.access$100(
    at org.junit.runners.ParentRunner$2.evaluate(
    at org.junit.runners.ParentRunner$3.evaluate(
    at org.mockito.internal.runners.DefaultInternalRunner$
    at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(
    at com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(
    at com.intellij.rt.execution.junit.TestsRepeater.repeat(
    at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(
    at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(
    at com.intellij.rt.junit.JUnitStarter.main(

Process finished with exit code 255

Moreover, with my unit tests working with the previous library version. There was a problem that during the execution of the unit tests, it used to print logs like WARN and ERROR in the console (which sometimes created a lot of confusion).


  • The line responsible for the error (in the version that you mentioned) looks like this (see

    if (throwableSuppressed.length > 0) {

    It's worth noting that there's a fix for your issue, although I have no idea what version of Logback might have it now or in the future. contains the following relevant change: Replaced

    if (throwableSuppressed.length > 0) {


    // while JDK's implementation of getSuppressed() will always return a non-null array,
    // this might not be the case in mocked throwables. We are being extra defensive here.
    if (OptionHelper.isNotEmtpy(throwableSuppressed)) {

    I'm generally not super keen on mocking Exceptions, myself. But if that's what your context demands, then mocking getSuppressed() to return a non-null (probably empty is fine) array might solve the issue.