TestContextManager.afterTestMethod doesn't handle java.lang.Error! [SPR-13961]

[spring-projects-issues]

Eduard V opened SPR-13961 and commented

In a org.springframework.test.context.TestContextManager.afterTestMethod(...) CALL to the configured test execution listeners is, naturally, surrounded by try/catch block that intercepts java.lang.Exception. Unfortunately, when the listener throws a java.lang.Error instead, it escapes into surrounding org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate() method, preventing the "downstream" listeners from being executed.

In my case, an offender was the org.dbunit.Assertion.assertEquals(...) methods, which throws java.lang.Error instead of promised org.dbunit.DatabaseUnitException when the assertion fails.

As a result:

• org.springframework.test.context.transaction.TransactionalTestExecutionListener.afterTestMethod(...) is never called;
• transaction is not committed/rolled back;
• database connection stays open and is not released back to the pool;
• subsequent test has a good chance to get stuck waiting for the DB lock.

Note: I am not sure how to categorize this issue, as a bug or as an improvement.
On the one hand, not catching Errors seems to be a correct behavior, as an Error is supposedly a catastrophic and unrecoverable event.
On the other hand, we get a bunch of stuck unit tests and leaked connections, all blocking each other which is not correct, desirable or ideal either.

---

Affects: 4.2.4

Issue Links:

• Regression: TestContextManager no longer tracks after-class exception with log level lower than WARN [SPR-14447] #19017 Regression: TestContextManager no longer tracks after-class exception with log level lower than WARN

Referenced from: commits 0adc492

[spring-projects-issues]

Juergen Hoeller commented

I would rather qualify this as an improvement in our terms, but a very valid one since we're catching Error in many other places as well, so it can arguably be expected here. Fixed for 4.3 now.

Juergen