What causes "Given index [{}] was outside the range of result tuple size [{}] " in hibernate/hibernate-orm?

Use 0-based indices strictly below size: valid range is `0 .. tuple.toArray().length - 1`

hibernate/hibernate-orm · error · IllegalArgumentException

Given index [{}] was outside the range of result tuple size

Error message

Given index [{}] was outside the range of result tuple size [{}]

What it means

Thrown by TupleImpl.get(int i) when the requested index is at or beyond the tuple size (row length). The message reports both the index and the size. Note the guard only checks the upper bound: a negative index is not checked here and would instead surface as an ArrayIndexOutOfBoundsException from the underlying array access.

Source

Thrown at hibernate-core/src/main/java/org/hibernate/sql/results/internal/TupleImpl.java:92

	public <X> X get(int i, Class<X> type) {
		final Object result = get( i );
		if ( result != null && !isInstance( type, result ) ) {
			throw new IllegalArgumentException(
					String.format(
							"Requested tuple value [index=%s, realType=%s] cannot be assigned to requested type [%s]",
							i,
							result.getClass().getName(),
							type.getName()
					)
			);
		}
		return cast( type, result );
	}

	@Override
	public Object get(int i) {
		if ( i >= row.length ) {
			throw new IllegalArgumentException(
					"Given index [" + i + "] was outside the range of result tuple size [" + row.length + "] "
			);
		}
		return row[i];
	}

	@Override
	public Object[] toArray() {
		return row;
	}

	@Override
	public List<TupleElement<?>> getElements() {
		return tupleMetadata.getList();
	}

	@Override
	public String toString() {

View on GitHub (pinned to fad1729dce)

Solutions

Use 0-based indices strictly below size: valid range is `0 .. tuple.toArray().length - 1`
Prefer alias-based access (`tuple.get("name")`) to eliminate index drift entirely
Derive the loop bound from the tuple itself: `Object[] arr = tuple.toArray(); for (int i=0; i<arr.length; i++)`

Example fix

// before
for (int i = 1; i <= tuple.toArray().length; i++) { Object v = tuple.get(i); }
// after
Object[] arr = tuple.toArray();
for (int i = 0; i < arr.length; i++) { Object v = arr[i]; }

Defensive patterns

Strategy: validation

Validate before calling

// Bounds check before indexed access (indices are 0-based)
int size = tuple.toArray().length;
if (i < 0 || i >= size) throw new IndexOutOfBoundsException("tuple index " + i + " of size " + size);

Try / catch

catch (IllegalArgumentException e) { if (e.getMessage().contains("outside the range of result tuple size")) { /* clamp or skip */ } throw e; }

Prevention

Remember: JPA Tuple indices are 0-based, unlike JDBC column positions (1-based)
Derive loop bounds from tuple.toArray().length, never from a hardcoded column count
Map indices once next to the query definition so reordering forces a visible update

When it happens

Trigger: `tuple.get(3)` on a 3-column select (valid indices 0-2); looping `for (int i=1; i<=size; i++) tuple.get(i)` - off-by-one treating positions as 1-based (JPA tuple indices are 0-based); select list shortened during refactoring while reader code kept old indices.

Common situations: Confusing JDBC 1-based column positions with Tuple 0-based indices; hardcoded indices drifting after query changes; reading dynamic projections where the column count varies.

Related errors

AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22). Data as JSON: /api/errors/5cb7929473d6bcf6. Report an issue: GitHub.