mybatis/mybatis-3 · error · ResultMapException
Error attempting to get column #" + columnIndex + " from cal
Error message
Error attempting to get column #" + columnIndex + " from callable statement. Cause: " + e
What it means
The CallableStatement variant of getResult: reading an OUT parameter by index from a stored procedure call failed inside getNullableResult, and BaseTypeHandler wrapped it in ResultMapException. The failing OUT parameter is identified by its 1-based position.
Source
Thrown at src/main/java/org/apache/ibatis/type/BaseTypeHandler.java:107
}
}
@Override
public T getResult(ResultSet rs, int columnIndex) throws SQLException {
try {
return getNullableResult(rs, columnIndex);
} catch (Exception e) {
throw new ResultMapException("Error attempting to get column #" + columnIndex + " from result set. Cause: " + e,
e);
}
}
@Override
public T getResult(CallableStatement cs, int columnIndex) throws SQLException {
try {
return getNullableResult(cs, columnIndex);
} catch (Exception e) {
throw new ResultMapException(
"Error attempting to get column #" + columnIndex + " from callable statement. Cause: " + e, e);
}
}
public abstract void setNonNullParameter(PreparedStatement ps, int i, T parameter, JdbcType jdbcType)
throws SQLException;
/**
* Gets the nullable result.
*
* @param rs
* the rs
* @param columnName
* Column name, when configuration <code>useColumnLabel</code> is <code>false</code>
*
* @return the nullable result
*
* @throws SQLExceptionView on GitHub (pinned to 008069adb1)
Solutions
- Compare the mapper's OUT parameter declarations (order and jdbcType) with the actual procedure signature
- Check the Cause: 'parameter not out' means mode was declared IN, wrong type means the handler mismatches
- Update the jdbcType/javaType (or explicit typeHandler) of the failing parameter to the procedure's real type
Example fix
// before
{CALL get_user(#{id,mode=IN},#{name,mode=OUT,jdbcType=VARCHAR})}
// after
{CALL get_user(#{id,mode=IN},#{name,mode=OUT,jdbcType=NVARCHAR})} -- match real proc type Defensive patterns
Strategy: try-catch
Try / catch
try { ... } catch (ResultMapException e) { // identifies the failing OUT param index; diff against the stored procedure signature } Prevention
- Keep a single source of truth for procedure signatures and regenerate mappers on change
- Declare mode=OUT and explicit jdbcType on every OUT parameter
- Integration-test stored-procedure mappers against a real database, not mocks
When it happens
Trigger: A {CALL ...} statement whose declared OUT parameters do not match the parameterMapper/resultMap order; the stored procedure changed its OUT parameter types; reading mode=OUT parameters with a handler for the wrong java type.
Common situations: Stored procedure signatures evolving without updating the mapper's parameterMap; Oracle/SQL Server procedures returning REF CURSOR or custom types handled by the wrong handler.
Related errors
- The JDBC Type must be specified for output parameter. Param
- Unknown execution method for: {name}
- Mapper method '{name}' attempted to return null from a metho
- Mapper method '{name}' has an unsupported return type: {retu
- method {name} needs either a @ResultMap annotation, a @Resul
AI-assisted analysis of mybatis/mybatis-3@008069adb1 (2026-08-14).
Data as JSON: /api/errors/18cd6a3a588b5091.
Report an issue: GitHub.