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 SQLException

View on GitHub (pinned to 008069adb1)

Solutions

  1. Compare the mapper's OUT parameter declarations (order and jdbcType) with the actual procedure signature
  2. Check the Cause: 'parameter not out' means mode was declared IN, wrong type means the handler mismatches
  3. 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

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


AI-assisted analysis of mybatis/mybatis-3@008069adb1 (2026-08-14). Data as JSON: /api/errors/18cd6a3a588b5091. Report an issue: GitHub.