db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: [JUnit] Should assertSQLState throw SQLException?
Date Tue, 22 Aug 2006 15:50:38 GMT
Rick Hillegas wrote:
> Alternatively, we could print out the stack trace ourselves. The logic 
> to do this could be re-usable by a general-purpose assertEquals() 
> overload which compares two Throwables. Failing by calling 
> assertEquals() seems like the way the JUnit wants to track errors.

I think it is perfectly acceptable to let the test methods throw 
"unexpected" exceptions as they are.

Many of our tests are a little special, because the only type of checked 
exceptions that can be thrown is SQLException. Thus we catch all 
exceptions with one catch-block.

For instance I think this kind of code is okay:

public void testSomething()
         throws XException, YException {
     methodCanThrowXException();
     mayThrowYException();
     methodCanThrowXException();
     try {
         shouldThrowYException();
         fail("An YException should have been thrown");
     } catch (YException ye) {
         assertEquals("myState", ye.getYState());
     }
}

I don't want to clutter my code with try-catches for unrelated 
exceptions, there's nothing I can do anyway. And if the unimaginable 
should happen and XException is thrown, I will have the stack trace (and 
hopefully other tests) to guide further investigations.

In the code above, note that the try-catch block is made as small as 
possible.

As Knut Anders, I also feel some information is missing when the tests 
fail. A five character SQLState does not tell me very much, and often I 
have to consult the messages file to see what it means! As a Derby 
example, let's say the method shouldThrowYException intermittently 
throws an exception with SQL state XSRS7.
Basically, this is what we have:
"expected: XSRS1, actual: XSRS7"

Let's consult the message text of XSRS7 for help:
"Backup caught unexpected exception."

That's all we got, and I don't feel too happy about that.
I can guess that some kind of IO exception caused this, but I want 
Derby/JUnit to tell me so I can be sure. If it can tell me where the 
error happened as well, it would be great!
Last, if the SQL state is not as expected, the test should result in a 
failure, not an error, but still preserve the stack trace.


Any suggestions on how we can achieve what Knut Anders is proposing?
I think it is a good proposal to preserve the stack trace, the error 
message and the SQL state.



-- 
Kristian


> 
> Regards,
> -Rick
> 
> Knut Anders Hatlen wrote:
> 
>> Currently, BaseJDBCTestCase.assertSQLState() and JDBC.assertSQLState()
>> basically do an assertEquals() on the SQL state. If the SQL state
>> doesn't match the expected value, an AssertionFailure is raised, but
>> the original exception is thrown away.
>>
>> Should we instead do something like this
>>  if (!expected.equals(sqle.getSQLState())) throw sqle;
>> ?
>>
>> This way, we preserve the stack trace and the error message, not only
>> the SQL state.
>>
>>  
>>
> 


Mime
View raw message