Tencent/APIJSON · error · IllegalArgumentException
{}/page:value 中 value 的值不合法!必须在 {}-{} 内 !
Error message
{}/page:value 中 value 的值不合法!必须在 {}-{} 内 ! What it means
The page number in []:{} is normalized (page or 0, minus getMinQueryPage(), commonly 0- or 1-based compat) and must fall in [0..getMaxQueryPage()]. Outside that range IllegalArgumentException is thrown with the exact min-max bounds in the message.
Source
Thrown at APIJSONORM/src/main/java/apijson/orm/AbstractParser.java:1372
case "1":
case apijson.JSONRequest.QUERY_TOTAL_STRING:
query2 = apijson.JSONRequest.QUERY_TOTAL;
break;
case "2":
case apijson.JSONRequest.QUERY_ALL_STRING:
query2 = apijson.JSONRequest.QUERY_ALL;
break;
default:
throw new IllegalArgumentException(path + "/" + apijson.JSONRequest.KEY_QUERY + ":value 中 value 的值不合法!必须在 [0, 1, 2] 或 [TABLE, TOTAL, ALL] 内 !");
}
}
int minPage = getMinQueryPage(); // 兼容各种传 0 或 null/undefined 自动转 0 导致的问题
int page2 = page == null || page == 0 ? 0 : page - minPage;
int maxPage = getMaxQueryPage();
if (page2 < 0 || page2 > maxPage) {
throw new IllegalArgumentException(path + "/" + apijson.JSONRequest.KEY_PAGE + ":value 中 value 的值不合法!必须在 " + minPage + "-" + maxPage + " 内 !");
}
//不用total限制数量了,只用中断机制,total只在query = 1,2的时候才获取
int count2 = isSubquery || count != null ? (count == null ? 0 : count) : getDefaultQueryCount();
int max = isSubquery ? count2 : getMaxQueryCount();
if (count2 < 0 || count2 > max) {
throw new IllegalArgumentException(path + "/" + apijson.JSONRequest.KEY_COUNT + ":value 中 value 的值不合法!必须在 0-" + max + " 内 !");
}
request.remove(apijson.JSONRequest.KEY_QUERY);
request.remove(apijson.JSONRequest.KEY_COMPAT);
request.remove(apijson.JSONRequest.KEY_COUNT);
request.remove(apijson.JSONRequest.KEY_PAGE);
request.remove(apijson.JSONRequest.KEY_JOIN);
Log.d(TAG, "onArrayParse query = " + query + "; count = " + count + "; page = " + page + "; join = " + join);
if (request.isEmpty()) { // 如果条件成立,说明所有的 parentPath/name:request 中request都无效!!! 后续都不执行,没必要还原数组关键词浪费性能View on GitHub (pinned to 5284052872)
Solutions
- Clamp page client-side to the range shown in the message (typically 0-100 or 1-100)
- When deep-paginating, use @column with ordered unique keys or @explain'd keyset pagination instead of high offsets
- Align the client's page base with getMinQueryPage() of the server
- Raise getMaxQueryPage() in your Parser subclass only if the data volume justifies it
Example fix
// before
{"[]":{"page":101,"count":10,"User":{}}}
// after
{"[]":{"page":100,"count":10,"User":{}}} Defensive patterns
Strategy: validation
Validate before calling
int p = page == null ? 0 : page;
if (p < 0 || p > MAX_PAGE) throw new IllegalArgumentException("page out of range: " + p); Type guard
boolean pageInRange(Integer page, int min, int max) {
return page == null || (page >= min && page <= max);
} Prevention
- Clamp page in the pager component using the server-advertised max
- Stop paginating when a response has fewer rows than count instead of probing higher pages
- Keyset-paginate with @order + @column for deep access
When it happens
Trigger: {"[]":{"page":100000,...}} beyond maxQueryPage (default 100), or a negative page, or page after normalization below 0 because the client assumed a different min-page base than the server uses.
Common situations: Client computes page from total/count without ceiling; infinite-scroll keeps incrementing past the cap; server tightened maxQueryPage to limit scan depth; off-by-one when minQueryPage is 1 on server but client sends 0-based 0 with negative computed index on another deploy.
Related errors
- {}/count:value 中 value 的值不合法!必须在 0-{} 内 !
- {}/query:value 中 value 的值不合法!必须在 [0, 1, 2] 或 [TABLE, TOTAL,
- join:'${e.getKey()}' 对应的 ${arrKey}:{ page: value } 中 value 不
- Value for key '" + key + "' is not a Map: " + value.getClass
- Value for key '" + key + "' is not a List: " + value.getClas
AI-assisted analysis of Tencent/APIJSON@5284052872 (2026-08-14).
Data as JSON: /api/errors/feca60b55ab3a7f4.
Report an issue: GitHub.