prestodb/presto · error · PrestoException

format(formatString, args)

Error message

format(formatString, args)

What it means

Failures.checkCondition is the general-purpose precondition helper: when condition is false it throws PrestoException with the caller-supplied ErrorCodeSupplier and a message built by format(formatString, args). Unlike checkArgument it lets call sites choose the error code, so it is used for user-facing semantic errors beyond plain argument validation.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/util/Failures.java:90

    public static void checkArgument(boolean expression, String errorMessage)
    {
        if (!expression) {
            throw new PrestoException(StandardErrorCode.INVALID_ARGUMENTS, errorMessage);
        }
    }

    public static void checkArgument(boolean expression, String errorMessageTemplate, Object... errorMessageArgs)
    {
        if (!expression) {
            throw new PrestoException(StandardErrorCode.INVALID_ARGUMENTS, String.format(errorMessageTemplate, errorMessageArgs));
        }
    }

    public static void checkCondition(boolean condition, ErrorCodeSupplier errorCode, String formatString, Object... args)
    {
        if (!condition) {
            throw new PrestoException(errorCode, format(formatString, args));
        }
    }

    public static List<ExecutionFailureInfo> toFailures(Collection<? extends Throwable> failures)
    {
        return failures.stream()
                .map(Failures::toFailure)
                .collect(toImmutableList());
    }

    private static ExecutionFailureInfo toFailure(Throwable throwable, Set<Throwable> seenFailures)
    {
        if (throwable == null) {
            return null;
        }

        String type;
        HostAddress remoteHost = null;

View on GitHub (pinned to 55bb57d202)

Solutions

1. Read the formatted message and the accompanying error code to identify the exact failing condition
2. Correct the query or configuration item the message points to
3. Use try_* functions or WHERE guards to filter out offending rows for data-dependent failures
4. Check feature/version compatibility — some checks fire when using features unsupported by the connected catalog

Example fix

-- before
SELECT from_hex('ZZ') ; -- invalid hex
-- after
SELECT from_hex(x) FROM t WHERE regexp_like(x, '^[0-9A-Fa-f]*$');

try { /* op */ } catch (PrestoException e) { Supplier<? extends ErrorCode> ec = e.getErrorCode(); log.error("checkCondition failed [{}]: {}", ec, e.getMessage()); /* branch on ec to recover or rethrow */ }

When it happens

Trigger: Any call to Failures.checkCondition(cond, errorCode, fmt, args...) where cond is false — e.g. session/property validation, function semantic checks, or connector checks that map to a specific SQL error code.

Common situations: Invalid session properties or catalog/schema state; queries violating function semantics (e.g. invalid hex, unsupported units); misconfigured connectors failing precondition checks at planning time.

Understand the failure class

Background: "must be a positive integer", "cannot be empty", "invalid argument": how invalid-argument errors work across open-source libraries — this error's family across 33 libraries.

Related errors

• INVALID_ARGUMENTS
• INVALID_TABLE_PROPERTY
• ACCUMULO_TABLE_EXISTS
• NOT_SUPPORTED
• UNEXPECTED_ACCUMULO_ERROR

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/06a20adc6ba5eaa9. Report an issue: GitHub.