Tencent/APIJSON · warning · WrongMethodTypeException

远程函数 " + methodName + " 的实际返回值类型 " + rt + " 与 Function 表中的配置

Error message

远程函数 " + methodName + " 的实际返回值类型 " + rt + " 与 Function 表中的配置的 " + returnType + " 不匹配！

What it means

In debug mode (Log.DEBUG == true), after reflectively invoking a Java remote function, APIJSON validates that the method's declared return type matches the returnType configured in the Function table row, throwing WrongMethodTypeException on mismatch. It only runs when debugging is enabled, acting as a development-time consistency check between code and table configuration.

Source

Thrown at APIJSONORM/src/main/java/apijson/orm/AbstractFunctionParser.java:515

        if (scriptExecutor != null) {
            return invokeScript(parser, methodName, parameterTypes, args, returnType, current, scriptExecutor);
        }

		Class<? extends AbstractFunctionParser> cls = parser.getClass();
        Method m = cls.getMethod(methodName, parameterTypes); // 不用判空，拿不到就会抛异常

        if (Log.DEBUG) {
            String rt = Log.DEBUG && m.getReturnType() != null ? m.getReturnType().getSimpleName() : null;

            if ("void".equals(rt)) {
                rt = null;
            }
            if ("void".equals(returnType)) {
                returnType = null;
            }

            if (rt != returnType && (rt == null || rt.equals(returnType) == false)) {
                throw new WrongMethodTypeException("远程函数 " + methodName + " 的实际返回值类型 " + rt + " 与 Function 表中的配置的 " + returnType + " 不匹配！");
            }
        }

        return m.invoke(parser, args);
	}

    /**Java 调用 JavaScript 函数
     * @param parser
     * @param methodName
     * @param parameterTypes
     * @param args
     * @param returnType
     * @param current
     * @return
     * @throws Exception
     */
	@SuppressWarnings({"unchecked", "rawtypes"})
    public static <T, M extends Map<String, Object>, L extends List<Object>> Object invokeScript(

View on GitHub (pinned to 5284052872)

Solutions

Update the Function table's returnType column to exactly match the Java method's return type (simple name, e.g. 'String').
Or change the Java method's return type to the configured one.
Treat this as a signal to reconcile the table — the mismatch may cause wrong response serialization in production.
If 'void' is involved, note both sides normalize void to null.

Example fix

-- before: method returns Long, table says returnType='String'
UPDATE sys.Function SET returnType='Long' WHERE name='enc';

-- or change Java: public String enc(...) { return String.valueOf(id); }

Defensive patterns

Strategy: validation

Validate before calling

if (Log.DEBUG) {
    Method m = parser.getClass().getMethod(fb.getMethod(), fb.getTypes());
    String declared = m.getReturnType().getSimpleName();
    String configured = (String) functionRow.get("returnType");
    boolean mismatch = !"void".equals(declared) && !"void".equals(configured)
        && !declared.equals(configured);
}

Try / catch

try { m.invoke(parser, args); } catch (WrongMethodTypeException e) { if (e.getMessage().contains("Function 表")) { /* sync returnType column with method return type */ } throw e; }

Prevention

Run dev/CI with Log.DEBUG=true to catch table/code drift before production.
When refactoring a function's return type, update the Function row in the same commit.
Automate a check comparing Function rows to parser method signatures.

When it happens

Trigger: Function table row says returnType='String' but the Java method is declared to return Object/Long; running with Log.DEBUG=true in a dev environment exposes the mismatch that production silently ignores.

Common situations: Method signature changed during refactoring without updating the Function row; demo rows have stale returnType values; switching debug on in a CI environment suddenly surfaces latent mismatches.

Related errors

AI-assisted analysis of Tencent/APIJSON@5284052872 (2026-08-14). Data as JSON: /api/errors/6a0de11a8328ddc3. Report an issue: GitHub.