tursodatabase/turso · error · UnsupportedOperationException
not implemented
Error message
not implemented
What it means
ResultSet.getWarnings() in the Turso JDBC4 driver unconditionally throws UnsupportedOperationException('not implemented'). The JDBC contract says getWarnings() returns the warning chain or null when there are no warnings, so this is a driver gap rather than a data problem - SQLite-family engines do not surface SQLWarnings.
Source
Thrown at bindings/java/src/main/java/tech/turso/jdbc4/JDBC4ResultSet.java:400
return getAsciiStream(findColumn(columnLabel));
}
@Override
@SkipNullableCheck
public InputStream getUnicodeStream(String columnLabel) throws SQLException {
return getUnicodeStream(findColumn(columnLabel));
}
@Override
@SkipNullableCheck
public InputStream getBinaryStream(String columnLabel) throws SQLException {
return getBinaryStream(findColumn(columnLabel));
}
@Override
@SkipNullableCheck
public SQLWarning getWarnings() throws SQLException {
throw new UnsupportedOperationException("not implemented");
}
@Override
public void clearWarnings() throws SQLException {
throw new UnsupportedOperationException("not implemented");
}
@Override
public String getCursorName() throws SQLException {
throw new UnsupportedOperationException("not implemented");
}
@Override
public ResultSetMetaData getMetaData() throws SQLException {
return this;
}
@OverrideView on GitHub (pinned to bad083fafb)
Solutions
- Remove the getWarnings() call - the engine produces no SQLWarnings to read
- Catch UnsupportedOperationException and treat the outcome as 'no warnings' (null)
- Contribute an implementation to bindings/java JDBC4ResultSet that returns null
Example fix
// before
SQLWarning w = rs.getWarnings();
// after
SQLWarning w = null;
try {
w = rs.getWarnings();
} catch (UnsupportedOperationException e) {
// driver does not track SQLWarnings
} Defensive patterns
Strategy: fallback
Try / catch
SQLWarning w;
try {
w = rs.getWarnings();
} catch (UnsupportedOperationException e) {
w = null; // driver tracks no warnings
} Prevention
- Do not build logic that depends on SQLWarnings on SQLite-family drivers
- Isolate driver capability gaps behind a small JDBC compatibility layer
When it happens
Trigger: Any direct call to rs.getWarnings() after executing a query, or indirect calls from generic JDBC wrappers, health checks, and verbose loggers that probe warnings after each statement.
Common situations: Code ported from xerial sqlite-jdbc or PostgreSQL drivers where getWarnings() returns null; shared JDBC utility classes; monitoring and tracing wrappers that log statement warnings.
Related errors
- column name not found
- column name {columnLabel} not found
- database connection closed
- Failed to convert ${sql} into bytes
- SQLite only supports TYPE_FORWARD_ONLY cursors
AI-assisted analysis of tursodatabase/turso@bad083fafb (2026-08-16).
Data as JSON: /api/errors/16ad202d0d47c8c4.
Report an issue: GitHub.