Daniel John Debrunner wrote:
DerbyJUnitTest has many cases where the SQLException thrown by Derby
(through JDBC) is ignored. To me, this seems very bad practice for test
code.
Isn't that bad practice for any code ?
Anyway, I think there are cases when you are interested in not throwing
the SQLException to the JUnit framework.
If your test has already failed with a meaningful assertion which
describes the error, the junit- test runner will call the tearDown()
method on your TestCase object, which may throw an exception.
If the tearDown() throws i.e "ResultSet is closed", that error will
overwrite the original test failure in the JUnit test report.
An alternative to swallowing the exception, is then of course to log it,
or to gather them somehow, and report them at the end of running the
testsuite.
For example:
//
// Swallow uninteresting exceptions when disposing of jdbc objects.
//
protected static void close( ResultSet rs )
{
try {
if ( rs != null ) { rs.close(); }
}
catch (SQLException e) {}
}
If ResultSet.close is throwing an exception when being closed then to my
mind that's a bug, but we would never see it through a Junit test.
Unless the resultset is already closed, or you have closed the
connection for the resultset.
Andreas
