Specify what should happen if Row.get(…) is called with a negative/out of bounds index/non-existing column name

[mp911de]

Right now, we're lacking a specification for Row.get(…) what should happen if the column index is out of bounds (negative, greater than the number of available columns) or a column name is used that isn't present in the result.

Analyzing the drivers yields the following behavior:

• MySQL: NoSuchElementException/ArrayIndexOutOfBoundsException
• Postgres: IllegalArgumentException
• SQL Server: IllegalArgumentException
• MariaDB: IllegalArgumentException
• Spanner: IllegalArgumentException
• H2: IllegalArgumentException

This ticket is to discuss the options and to agree on how implementations of Row.get(…) should behave.

[mp911de]

After discussing the ticket in the monthly call, we want to do something about this. The design choices range from a R2dbcException subtype to the use of built-in Java exceptions.

[elefeint]

I just wanted to make sure I did not mislead in the meeting -- I think IllegalArgumentException is semantically perfectly appropriate; I was not trying to tip the scales towards a custom exception.

[mp911de]

All good, these are all valid options.

[Michael-A-McMahon]

I agree that IllegalArgumentException seems like the best choice, as it is one of the exception types listed in section 11 of the 0.8.x specification. Drivers should follow the spec.

When invoking Row.get(...) with an invalid index or name, IllegalArgumentException seems more descriptive than IllegalStateException or UnsupportedOperationException. R2dbcException would signify a failed database interaction, so is not applicable here.

[lukaseder]

R2dbcException would signify a failed database interaction, so is not applicable here.

Well, the JDBC precedent is ResultSet.getXYZ() throws SQLException...

[mp911de]

The problem with JDBC is that everything is an SQLException and drivers do not consistently implement the entire exception hierarchy.

[lukaseder]

and drivers do not consistently implement the entire exception hierarchy.

Same as here, given your initial issue text? 😀

[mp911de]

Right now, the error behavior isn't specified so everyone is doing something different and now we have the chance to clean up things and actually put them into the TCK to help implementors convince towards the spec.

[mp911de]

We make already use of IndexOutOfBoundsException in Statement.bind(…). It would make sense to follow the line of thought and use the same exception in Readable.get and metadata classes. Also make use of NoSuchElementException as a more descriptive exception for get(String), getColumnMetadata(String) and other places. We don't need to introduce new exceptions, rather we use what the Java standard libraries provide.