You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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:
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:
Referenced from: commits 0adc492
The text was updated successfully, but these errors were encountered: