I'm a bit at a loss here. I'm supposed to write an implementation of javax.sql.RowSet
for a specific purpose and I'm trying to unit-test it as well as far as I can.
Now, a ResultSet
has a cursor that can be on a normal row (or before the first or after the last) or on the insert row. moveToInsertRow()
says:
Only the updater, getter, and insertRow methods may be called when the cursor is on the insert row.
Nothing is said on what is supposed to happen then. next()
is less helpful by not even pointing that case out:
Moves the cursor forward (sic!) one row from its current position. A
ResultSet
cursor is initially positioned before the first row; the first call to the method next makes the first row the current row; the second call makes the second row the current row, and so on.When a call to the next method returns
false
, the cursor is positioned after t开发者_StackOverflow社区he last row. Any invocation of aResultSet
method which requires a current row will result in aSQLException
being thrown. If the result set type isTYPE_FORWARD_ONLY
, it is vendor specified whether their JDBC driver implementation will returnfalse
or throw anSQLException
on a subsequent call tonext
.If an input stream is open for the current row, a call to the method
next
will implicitly close it. AResultSet
object's warning chain is cleared when a new row is read.Returns:
true
if the new current row is valid;false
if there are no more rowsThrows:
SQLException
- if a database access error occurs or this method is called on a closed result set
I have no prior experience with the JDBC APIs and therefore have no clue whether that's intentionally unspecified (undefined behavior maybe?) or just an oversight.
Currently I think I'd just throw an SQLException
even though that's nowhere specified and thus maybe UnsupportedOperationException
would be better (as SQLException
signals a DB error or a closed ResultSet
– neither of which would be the case here).
Or did I just miss a bit of documentation somewhere?
I suggest you follow the contract of moveToInsertRow()
and throw some sort of exception (SQL-
or IllegalState-
). This is going to cause the least trouble if people mistakenly call next()
.
You could also have a look at others' implementation to see what they do (MySQL Connector/J for example) so that other frameworks you use won't get surprised.
How about just writing a small program to actually test the behavior of next()
after moveToInsertRow()
?
I'm a TDDer but sometimes when I'm programming something that uses a "foreign" API I would create a small proof of concept that is not really test driven, usually called a "spike", that way I can learn how the different API calls interact. When I feel like I have a good grasp of the API I just throw the spike away and start coding in normal TDD fashion.
精彩评论