export { N as NextlyError, a as NextlyErrorResponseJSON, P as PublicData, R as RateLimitPublicData, V as ValidationPublicData } from '../_dts-chunks/nextly-error.d-WlStqaV9.d.ts';
export { N as NEXTLY_ERROR_STATUS, a as NextlyErrorCode } from '../_dts-chunks/error-codes.d-CbwkO1ux.d.ts';

/**
 * Developer-facing rendering of a thrown value.
 *
 * `NextlyError.message` is deliberately the public message, so anything that
 * renders a caught error with `error.message` shows the generic wire text
 * ("An unexpected error occurred.") and drops the code, the cause and the log
 * context. That is the correct behaviour on the wire and the wrong behaviour
 * on an operator channel: a server log or a terminal.
 *
 * This builds the operator view instead, pulling the structured fields that
 * identify the failure. Stack traces are deliberately excluded — they are the
 * noisy part, and callers that want them render `cause.stack` behind a flag.
 *
 * @module errors/describe-error
 */
/**
 * The thrown value's own message, with no cause chain appended.
 *
 * Use this, never `describeError`, when the result feeds a decision. Code that
 * asks "is this the benign 'already exists' case?" by substring match must see
 * only the immediate failure: `describeError` concatenates the whole chain, so
 * an unrelated error that merely *wraps* something containing the phrase would
 * match and be swallowed. Descriptions are for reading; this is for branching.
 *
 * Substring-matching a driver message is itself a weak test. It is preserved
 * here because replacing it is a separate change, but new code should prefer a
 * structured signal such as `DbError.kind`.
 */
declare function immediateMessage(error: unknown): string;
/** Options for {@link describeError}. */
interface DescribeErrorOptions {
    /**
     * Append `logContext`. Default true.
     *
     * Set false when the result is PERSISTED rather than printed. A terminal
     * line is read once and discarded; a stored row outlives the incident and
     * may be served back over an API, so the arbitrary identifiers and values a
     * log context can carry are worth leaving out of it. The code, message and
     * cause chain carry the diagnostic value and are kept either way.
     */
    context?: boolean;
}
/**
 * Build a developer-readable description of any thrown value.
 *
 * For a `NextlyError` this is `[CODE] public message | cause: … | context: {…}`.
 * For a plain `Error` it is the message plus any cause chain. For anything else
 * it is a best-effort stringification.
 */
declare function describeError(error: unknown, options?: DescribeErrorOptions): string;

/**
 * Telling our bugs apart from the caller's mistakes.
 *
 * Service layers commonly wrap their body in one try/catch and map anything
 * thrown onto a single fallback status. That is right for expected failures
 * (invalid input, a missing row) and wrong for a defect in our own code: a
 * `TypeError` from a bad property access surfaces to the caller as
 * "Validation failed", so they inspect a payload that was never the problem
 * while the real defect leaves no trace at the status code.
 *
 * @module errors/programmer-error
 */
/**
 * Whether a thrown value indicates a defect in Nextly rather than bad input.
 *
 * Only `TypeError` and `ReferenceError` qualify. Both are raised by the
 * runtime for operations that are wrong regardless of input: reading a
 * property of `undefined`, calling a non-function, touching an unbound
 * identifier.
 *
 * `SyntaxError` and `RangeError` are deliberately excluded even though they
 * are also natives. `JSON.parse` of a caller-supplied body throws
 * `SyntaxError`, and a caller-supplied count throws `RangeError`; treating
 * either as our defect would turn genuine 4xx cases into 500s, which is the
 * same misreporting in the other direction.
 */
declare function isProgrammerError(error: unknown): boolean;

export { describeError, immediateMessage, isProgrammerError };