@setu-ts/exceptions 0.0.0-stage → 0.9.0

package/src/errors/exceptions.ts

@@ -0,0 +1,212 @@
+/**
+ * Exception factory functions.
+ *
+ * Each factory returns a {@linkcode HttpError} with a fixed `statusCode`,
+ * embodying **composition over inheritance** (AI_GUIDELINES §1.4,
+ * ARCHITECTURE.md §13). Throw one in a route handler or service and the
+ * error-handler middleware will format and send it with the right status.
+ *
+ * @example
+ * ```typescript
+ * import { notFound, badRequest } from '@setu-ts/exceptions';
+ *
+ * function getUser(id: string) {
+ *   if (!id) throw badRequest('id is required');
+ *   const user = db.find(id);
+ *   if (!user) throw notFound(`User ${id} not found`);
+ *   return user;
+ * }
+ * ```
+ *
+ * @module
+ */
+import { HttpError } from './http-error.ts';
+import type { ValidationError } from './http-error.ts';
+
+// ---------------------------------------------------------------------------
+// Status-code → human title (single source of truth, shared with formatters)
+// ---------------------------------------------------------------------------
+
+/**
+ * A human-readable title for a given HTTP status code. This is the single
+ * source of truth used by both the factory functions and the Problem Details
+ * formatters so the `title` field never drifts from the produced `statusCode`.
+ *
+ * Keys are every status the framework itself produces — the ones the factories
+ * below return AND the ones first-party code brands onto an error with
+ * `withHttpStatusHint` from `@setu-ts/common`, which reaches this table through
+ * the responder seam without passing a factory (`413` from the request-size and
+ * body-cap refusals, `415` from the form accessor, `501`/`503`/`504` from the
+ * database, secrets and resilience refusals). A branded status with no row here
+ * is served the generic `'Error'` title, so `test/status-title-coverage.test.ts`
+ * enumerates the branded statuses from source and fails when one is missing —
+ * `415` reached a client as `"title": "Error"` under `'rfc9457'` while the same
+ * error read `"message": "Unsupported Media Type"` under `'default'`, because
+ * every test asserted the brand on the error object and none read the served
+ * body.
+ *
+ * @since 0.1.0
+ */
+export const STATUS_TITLES: Readonly<Record<number, string>> = {
+  400: 'Bad Request',
+  401: 'Unauthorized',
+  403: 'Forbidden',
+  404: 'Not Found',
+  409: 'Conflict',
+  413: 'Payload Too Large',
+  415: 'Unsupported Media Type',
+  422: 'Unprocessable Entity',
+  429: 'Too Many Requests',
+  500: 'Internal Server Error',
+  501: 'Not Implemented',
+  502: 'Bad Gateway',
+  503: 'Service Unavailable',
+  504: 'Gateway Timeout',
+};
+
+/**
+ * Resolves the human-readable title for a status code, falling back to a
+ * generic title for codes outside the well-known set.
+ *
+ * @param statusCode - The HTTP status code
+ * @returns A human-readable title
+ * @since 0.1.0
+ */
+export function statusTitle(statusCode: number): string {
+  return STATUS_TITLES[statusCode] ?? 'Error';
+}
+
+// ---------------------------------------------------------------------------
+// Factories
+// ---------------------------------------------------------------------------
+
+/**
+ * Creates a `400 Bad Request` error.
+ *
+ * @param message - Human-readable error message
+ * @param details - Optional structured details appended to the error body
+ * @returns A `400` {@linkcode HttpError}
+ * @since 0.1.0
+ */
+export function badRequest(
+  message: string,
+  details?: Readonly<Record<string, unknown>>,
+): HttpError {
+  return new HttpError(400, message, details);
+}
+
+/**
+ * Creates a `401 Unauthorized` error.
+ *
+ * @param message - Human-readable error message
+ * @returns A `401` {@linkcode HttpError}
+ * @since 0.1.0
+ */
+export function unauthorized(message: string): HttpError {
+  return new HttpError(401, message);
+}
+
+/**
+ * Creates a `403 Forbidden` error.
+ *
+ * @param message - Human-readable error message
+ * @returns A `403` {@linkcode HttpError}
+ * @since 0.1.0
+ */
+export function forbidden(message: string): HttpError {
+  return new HttpError(403, message);
+}
+
+/**
+ * Creates a `404 Not Found` error.
+ *
+ * @param message - Human-readable error message
+ * @returns A `404` {@linkcode HttpError}
+ * @since 0.1.0
+ */
+export function notFound(message: string): HttpError {
+  return new HttpError(404, message);
+}
+
+/**
+ * Creates a `409 Conflict` error.
+ *
+ * @param message - Human-readable error message
+ * @returns A `409` {@linkcode HttpError}
+ * @since 0.1.0
+ */
+export function conflict(message: string): HttpError {
+  return new HttpError(409, message);
+}
+
+/**
+ * Creates a `422 Unprocessable Entity` error wrapping a list of validation
+ * failures.
+ *
+ * The `errors` array is stored in the error's `details.errors` so it survives
+ * serialization into both the default and RFC 7807 error bodies.
+ *
+ * @param errors - The validation failures that caused this error
+ * @param message - Optional custom message (defaults to a count-based summary)
+ * @returns A `422` {@linkcode HttpError}
+ * @since 0.1.0
+ */
+export function validationError(
+  errors: readonly ValidationError[],
+  message?: string,
+): HttpError {
+  const summary = message ?? `Validation failed with ${errors.length} error(s).`;
+  return new HttpError(422, summary, { errors });
+}
+
+/**
+ * Creates a `429 Too Many Requests` error.
+ *
+ * @param message - Human-readable error message
+ * @param details - Optional structured details (e.g. `retryAfter`)
+ * @returns A `429` {@linkcode HttpError}
+ * @since 0.1.0
+ */
+export function tooManyRequests(
+  message: string,
+  details?: Readonly<Record<string, unknown>>,
+): HttpError {
+  return new HttpError(429, message, details);
+}
+
+/**
+ * Creates a `500 Internal Server Error` error.
+ *
+ * Pass the original error as `cause` so the root cause is preserved in the
+ * ES2022 error chain for logging and debugging.
+ *
+ * @param message - Human-readable error message
+ * @param cause - Optional underlying error forwarded to the cause chain
+ * @returns A `500` {@linkcode HttpError}
+ * @since 0.1.0
+ */
+export function internalServerError(message: string, cause?: Error): HttpError {
+  return new HttpError(500, message, undefined, cause);
+}
+
+/**
+ * Creates a `501 Not Implemented` error.
+ *
+ * @param message - Human-readable error message
+ * @returns A `501` {@linkcode HttpError}
+ * @since 0.1.0
+ */
+export function notImplemented(message: string): HttpError {
+  return new HttpError(501, message);
+}
+
+/**
+ * Creates a `503 Service Unavailable` error.
+ *
+ * @param message - Human-readable error message
+ * @returns A `503` {@linkcode HttpError}
+ * @since 0.1.0
+ */
+export function serviceUnavailable(message: string): HttpError {
+  return new HttpError(503, message);
+}

package/src/errors/http-error.ts

@@ -0,0 +1,132 @@
+/**
+ * `HttpError` — the framework's single concrete HTTP error type.
+ *
+ * Rather than a deep class hierarchy (`BadRequestError extends HttpError`,
+ * `NotFoundError extends HttpError`, …), the framework uses **composition via
+ * factory functions** (AI_GUIDELINES §1.4, ARCHITECTURE.md §13). Every HTTP
+ * error is an instance of this one class with a `statusCode` set at
+ * construction time by a factory. This keeps the hierarchy flat, makes errors
+ * trivially serializable, and allows runtime composition of properties.
+ *
+ * `cause` is forwarded to the ES2022 `Error` cause chain — pass the original
+ * error so callers can inspect the root cause without losing the stack.
+ *
+ * @module
+ */
+
+/**
+ * A single validation failure carried by a `422` error.
+ *
+ * Mirrors the shape used by `@setu-ts/validation-plugin` so error
+ * payloads are consistent across the validation and exceptions packages.
+ *
+ * @since 0.1.0
+ */
+export interface ValidationError {
+  /** Dot-path of the offending field (e.g. `"address.zip"`). */
+  readonly field: string;
+  /** Human-readable description of the failure. */
+  readonly message: string;
+  /** Optional machine-readable failure code. */
+  readonly code?: string;
+}
+
+/**
+ * Options accepted by the {@linkcode HttpError} constructor.
+ *
+ * Extracted as a type so factory functions can accept a consistent object.
+ *
+ * @since 0.1.0
+ */
+export interface HttpErrorInit {
+  /** HTTP status code (e.g. `404`). */
+  readonly statusCode: number;
+  /** Human-readable error message. */
+  readonly message: string;
+  /** Optional structured details attached to the error body. */
+  readonly details?: Readonly<Record<string, unknown>>;
+  /** Optional underlying cause (forwarded to the ES2022 `Error` cause chain). */
+  readonly cause?: Error;
+}
+
+/**
+ * The framework's HTTP error type.
+ *
+ * Throw an instance directly, or — preferably — construct one via a factory
+ * function from {@linkcode ./exceptions.ts} so the status code is correct by
+ * construction:
+ *
+ * @example
+ * ```typescript
+ * import { notFound } from '@setu-ts/exceptions';
+ *
+ * throw notFound(`User ${id} not found`);
+ * ```
+ *
+ * The error handler middleware inspects the `statusCode` to set the response
+ * status, and serializes `message` and `details` into the error body.
+ *
+ * @since 0.1.0
+ */
+export class HttpError extends Error {
+  /** The HTTP status code this error maps to. */
+  readonly statusCode: number;
+  /**
+   * Structured details appended to the error body. Omitted entirely when not
+   * supplied (never `undefined`) so serialization stays clean.
+   *
+   * `declare` suppresses the ES2022 class-field initialization that would
+   * otherwise set this to `undefined` on every instance — it only exists on
+   * the object when actually assigned by the constructor.
+   */
+  declare readonly details?: Readonly<Record<string, unknown>>;
+
+  /**
+   * Creates a new `HttpError`.
+   *
+   * Prefer the factory functions in `exceptions.ts` over calling this
+   * constructor directly — they guarantee a correct status code.
+   *
+   * @param statusCode - HTTP status code (e.g. `404`)
+   * @param message - Human-readable error message
+   * @param details - Optional structured details; omitted when absent
+   * @param cause - Optional underlying error; forwarded to the ES2022 cause chain
+   *
+   * @example
+   * ```typescript
+   * const err = new HttpError(404, 'User not found');
+   * console.log(err.statusCode); // 404
+   * ```
+   * @since 0.1.0
+   */
+  constructor(
+    statusCode: number,
+    message: string,
+    details?: Readonly<Record<string, unknown>>,
+    cause?: Error,
+  ) {
+    // Forward `cause` to the ES2022 Error cause chain when present. Under
+    // `exactOptionalPropertyTypes`, passing `{ cause: undefined }` would
+    // violate the option, so the options object is built conditionally.
+    super(message, cause !== undefined ? { cause } : undefined);
+    this.name = 'HttpError';
+    this.statusCode = statusCode;
+    if (details !== undefined) {
+      this.details = details;
+    }
+  }
+
+  /**
+   * Creates an `HttpError` from an {@linkcode HttpErrorInit} object.
+   *
+   * Convenience overload used by factory functions so they can branch on
+   * optional `details`/`cause` once.
+   *
+   * @param init - The error options
+   * @returns A new `HttpError`
+   * @since 0.1.0
+   */
+  static from(init: HttpErrorInit): HttpError {
+    return new HttpError(init.statusCode, init.message, init.details, init.cause);
+  }
+}

package/src/formatters/error-formatter.ts

@@ -0,0 +1,127 @@
+/**
+ * Error format selector — resolves the configured error format to a concrete
+ * formatter function.
+ *
+ * Supported formats:
+ * - `'default'` — Framework-standard error shape (`statusCode`, `message`,
+ *   optional `details`).
+ * - `'rfc9457'` — RFC 9457 Problem Details (see `rfc9457-formatter.ts`).
+ * - `'rfc7807'` — deprecated; RFC 7807 Problem Details (see
+ *   `rfc7807-formatter.ts`). RFC 7807 was obsoleted by RFC 9457.
+ * - A custom function — used as-is.
+ *
+ * @module
+ */
+import type { IRequestContext } from '@setu-ts/common';
+
+import { rfc9457Formatter } from './rfc9457-formatter.ts';
+import { rfc7807Formatter } from './rfc7807-formatter.ts';
+import { HttpError } from '../errors/http-error.ts';
+
+// ---------------------------------------------------------------------------
+// Types
+// ---------------------------------------------------------------------------
+
+/**
+ * A function that formats a thrown error into a serializable error body.
+ *
+ * @param error - The thrown error (an `HttpError` or a generic `Error`)
+ * @param ctx - Optional request context (used for `instance`, logging, etc.)
+ * @returns The formatted error body
+ * @since 0.1.0
+ */
+export type ErrorHandlerFormatter = (
+  error: Error,
+  ctx?: IRequestContext,
+) => Record<string, unknown>;
+
+/**
+ * The built-in error format identifiers for `@setu-ts/exceptions`.
+ *
+ * `'rfc7807'` is retained for backward compatibility and resolves to the
+ * deprecated {@linkcode rfc7807Formatter}; prefer `'rfc9457'`.
+ *
+ * @since 0.1.0
+ */
+export type ErrorFormat = 'default' | 'rfc9457' | 'rfc7807';
+
+// ---------------------------------------------------------------------------
+// Built-in default formatter
+// ---------------------------------------------------------------------------
+
+/**
+ * The framework-standard error body shape.
+ *
+ * @since 0.1.0
+ */
+export interface DefaultErrorBody {
+  /** The HTTP status code. */
+  readonly statusCode: number;
+  /** Human-readable error message. */
+  readonly message: string;
+  /** Optional structured details (present when the error carries any). */
+  readonly details?: Readonly<Record<string, unknown>>;
+  /** Optional stack trace (present only when `includeStackTrace` is on). */
+  readonly stack?: string;
+  /** Allow callers to attach further members. */
+  readonly [key: string]: unknown;
+}
+
+/**
+ * Framework-standard error formatter.
+ *
+ * Returns a body shaped as:
+ *
+ * ```json
+ * { "statusCode": 404, "message": "User not found", "details": { ... } }
+ * ```
+ *
+ * Generic (non-`HttpError`) errors map to `500`.
+ *
+ * @param error - The thrown error to format
+ * @returns The default formatted error body
+ * @since 0.1.0
+ */
+export const defaultFormatter: ErrorHandlerFormatter = (error: Error): DefaultErrorBody => {
+  const isHttp = error instanceof HttpError;
+  return {
+    statusCode: isHttp ? error.statusCode : 500,
+    message: error.message,
+    ...(isHttp && error.details !== undefined && { details: error.details }),
+  };
+};
+
+// ---------------------------------------------------------------------------
+// Selector
+// ---------------------------------------------------------------------------
+
+/**
+ * Resolve the error format configuration to a concrete formatter function.
+ *
+ * - When `format` is `'default'`, `'rfc9457'`, or the deprecated `'rfc7807'`,
+ *   the corresponding built-in formatter is returned.
+ * - When `format` is already a function, it is returned as-is.
+ * - Otherwise a `TypeError` is thrown.
+ *
+ * @param format - The error format identifier or custom formatter function
+ * @returns The resolved formatter function
+ * @throws {TypeError} When an unknown format string is provided
+ * @since 0.1.0
+ */
+export function selectFormatter(
+  format: ErrorFormat | ErrorHandlerFormatter = 'default',
+): ErrorHandlerFormatter {
+  if (typeof format === 'function') {
+    return format;
+  }
+  switch (format) {
+    case 'default':
+      return defaultFormatter;
+    case 'rfc9457':
+      return rfc9457Formatter;
+    case 'rfc7807':
+      return rfc7807Formatter;
+    default:
+      throw new TypeError(`Unknown error format: "${format}"`);
+  }
+}

package/src/formatters/problem-details.ts

@@ -0,0 +1,176 @@
+/**
+ * Shared Problem Details assembly.
+ *
+ * Both the RFC 9457 formatter and the deprecated RFC 7807 one produce the same
+ * body apart from the `type` member, so the assembly lives here once and each
+ * formatter supplies only its own {@linkcode ProblemTypeResolver}
+ * (AI_GUIDELINES §11.1).
+ *
+ * This module is internal: `buildProblemDetails` and `ProblemTypeResolver` are
+ * not exported from `src/index.ts`. `ERROR_TYPE_BASE` and `ProblemDetails` are
+ * re-exported publicly by `rfc9457-formatter.ts`.
+ *
+ * @module
+ */
+import type { IRequestContext } from '@setu-ts/common';
+
+import { statusTitle } from '../errors/exceptions.ts';
+import { HttpError } from '../errors/http-error.ts';
+
+/**
+ * The canonical base URI for framework-produced problem type identifiers.
+ *
+ * @since 0.1.0
+ */
+export const ERROR_TYPE_BASE = 'https://setu-ts.dev/errors';
+
+/**
+ * The problem type URI identifying a validation failure.
+ *
+ * Spelled to match the literal `@setu-ts/validation-plugin` emits, so both
+ * packages identify the same problem type with the same URI. The two cannot
+ * share a constant — a package may not import another package's internals
+ * (AI_GUIDELINES §2.2) — so the agreement is pinned by a test in each.
+ *
+ * @since 0.1.0
+ */
+export const VALIDATION_TYPE: string = `${ERROR_TYPE_BASE}/validation`;
+
+/**
+ * The RFC 9457 default problem type, meaning "no semantics beyond the HTTP
+ * status code" (RFC 9457 §4.2).
+ *
+ * @since 0.1.0
+ */
+export const ABOUT_BLANK = 'about:blank';
+
+/**
+ * A Problem Details object as defined by
+ * [RFC 9457](https://www.rfc-editor.org/rfc/rfc9457.html).
+ *
+ * Extension members beyond the five core fields are allowed (RFC 9457 §3.2),
+ * so `errors` and `stack` may be present.
+ *
+ * @since 0.1.0
+ */
+export interface ProblemDetails {
+  /** A URI reference identifying the problem type. */
+  readonly type: string;
+  /** A short, human-readable summary of the problem type. */
+  readonly title: string;
+  /** The HTTP status code generated for this occurrence. */
+  readonly status: number;
+  /** A human-readable explanation specific to this occurrence. */
+  readonly detail: string;
+  /** A URI reference identifying the specific occurrence (request path). */
+  readonly instance?: string;
+  /** Optional validation failures extension (present for `422` errors). */
+  readonly errors?: ReadonlyArray<{
+    field: string;
+    message: string;
+    code?: string;
+  }>;
+  /** Optional stack trace (present only when `includeStackTrace` is on). */
+  readonly stack?: string;
+  /** Allow callers to attach further extension members. */
+  readonly [key: string]: unknown;
+}
+
+/**
+ * Marks an {@linkcode HttpError} as one the M70f error responder built, and
+ * carries the calling site's disclosure.
+ *
+ * The responder must hand the disclosure to the Problem Details formatters as
+ * the `detail` member while leaving the site's title as the error `message`
+ * (which the `default` formatter emits verbatim). It cannot use
+ * `HttpError.details` alone as that channel: `details` is a free-form bag an
+ * application writes into too, so promoting any `details.detail` would change
+ * the body of a thrown error that merely uses the same key name.
+ *
+ * This marker is a module-private `Symbol` — not `Symbol.for` — because both
+ * writer ({@linkcode ../middleware/error-responder-impl.ts}) and reader
+ * ({@linkcode buildProblemDetails}) live in this package and import it
+ * directly; a global registry key would expose an internal channel that a
+ * third party could forge.
+ *
+ * @internal
+ */
+export const RESPONDER_DETAIL: unique symbol = Symbol('setu.exceptions.responder-detail');
+
+/**
+ * Resolves the `type` member of a Problem Details body.
+ *
+ * @param statusCode - The HTTP status code of the occurrence
+ * @param hasErrors - Whether the error carries a validation `errors` extension
+ * @returns The problem type URI
+ * @since 0.1.0
+ */
+export type ProblemTypeResolver = (statusCode: number, hasErrors: boolean) => string;
+
+/**
+ * Extracts the validation `errors` extension from an error's `details`, if any.
+ *
+ * @param error - The HTTP error to read
+ * @returns The validation failures, or `undefined` when the error carries none
+ */
+function extractErrors(error: HttpError): ProblemDetails['errors'] {
+  const details = error.details;
+  if (details === undefined || !('errors' in details)) {
+    return undefined;
+  }
+  return details.errors as ProblemDetails['errors'];
+}
+
+/**
+ * Assembles a Problem Details body from a thrown error.
+ *
+ * - `status` and `detail` come from the {@linkcode HttpError} (or default to
+ *   `500` / the error message for generic `Error`s).
+ * - `title` is derived from the status code via the shared status-title map.
+ * - `instance` is the request path when a context is supplied.
+ * - `errors` is included when the error carries validation details.
+ * - `type` is delegated to `resolveType`, the only member the two supported
+ *   specification versions disagree on.
+ *
+ * @param error - The thrown error to format
+ * @param ctx - Optional request context (used for `instance`)
+ * @param resolveType - Strategy supplying the `type` member
+ * @returns A Problem Details body
+ * @since 0.1.0
+ */
+export function buildProblemDetails(
+  error: Error,
+  ctx: IRequestContext | undefined,
+  resolveType: ProblemTypeResolver,
+): ProblemDetails {
+  const isHttp = error instanceof HttpError;
+  const statusCode = isHttp ? error.statusCode : 500;
+  const errors = isHttp ? extractErrors(error) : undefined;
+  // A responder-built error carries the site's disclosure in its structured
+  // details under a `detail` key (M70f); the Problem Details `detail` member
+  // is that disclosure, falling back to the error message (the title) when a
+  // site supplied none.
+  //
+  // The promotion is gated on {@linkcode RESPONDER_DETAIL}, NOT on the mere
+  // presence of a `detail` key, because `HttpError.details` is a free-form bag
+  // an application also writes into: reading any `details.detail` would
+  // silently change the `detail` member of a thrown
+  // `new HttpError(400, 'Invalid payload', { detail: 'code-7' })` from its
+  // message to `'code-7'` — a released-behaviour change to every application
+  // that happens to use that key name (M70f code review, finding 4). Only an
+  // error the responder built carries the marker, so a thrown error keeps the
+  // pre-M70f shape: `detail` is the message.
+  const carriedDetail = isHttp && RESPONDER_DETAIL in error
+    ? (error as HttpError & { [RESPONDER_DETAIL]?: unknown })[RESPONDER_DETAIL]
+    : undefined;
+  const detail = typeof carriedDetail === 'string' ? carriedDetail : error.message;
+
+  return {
+    type: resolveType(statusCode, errors !== undefined),
+    title: statusTitle(statusCode),
+    status: statusCode,
+    detail,
+    ...(ctx !== undefined && { instance: ctx.request.path }),
+    ...(errors !== undefined && { errors }),
+  };
+}

package/src/formatters/rfc7807-formatter.ts

@@ -0,0 +1,48 @@
+/**
+ * RFC 7807 Problem Details error formatter (deprecated).
+ *
+ * RFC 7807 was obsoleted by [RFC 9457](https://www.rfc-editor.org/rfc/rfc9457.html)
+ * in July 2023. This formatter is retained unchanged so existing callers keep
+ * their exact body shape through a deprecation period (AI_GUIDELINES §9.2); new
+ * code should use `rfc9457-formatter.ts`.
+ *
+ * It differs from the RFC 9457 formatter in the `type` member alone: this one
+ * mints a URI from the status code for every error, which RFC 9457 §4.2 replaces
+ * with `about:blank` for problems carrying no semantics beyond that status.
+ *
+ * @module
+ */
+import type { IRequestContext } from '@setu-ts/common';
+
+import type { ErrorHandlerFormatter } from './error-formatter.ts';
+import { buildProblemDetails, ERROR_TYPE_BASE, type ProblemDetails } from './problem-details.ts';
+
+/**
+ * Resolves the RFC 7807 `type` member: a URI minted from the status code.
+ *
+ * @param statusCode - The HTTP status code of the occurrence
+ * @returns The status-derived problem type URI
+ */
+const resolveRfc7807Type = (statusCode: number): string => `${ERROR_TYPE_BASE}/${statusCode}`;
+
+/**
+ * Format an error as RFC 7807 Problem Details.
+ *
+ * @param error - The thrown error to format
+ * @param ctx - Optional request context (used for `instance`)
+ * @returns An RFC 7807 Problem Details body
+ * @deprecated RFC 7807 was obsoleted by RFC 9457. Use `rfc9457Formatter`
+ * instead, or the `'rfc9457'` format alias. Will be removed in v1.0.0.
+ * @example
+ * ```typescript
+ * // Before
+ * app.middleware.add(errorHandler({ format: 'rfc7807' }));
+ * // After — `type` becomes 'about:blank' for status-only problems
+ * app.middleware.add(errorHandler({ format: 'rfc9457' }));
+ * ```
+ * @since 0.1.0
+ */
+export const rfc7807Formatter: ErrorHandlerFormatter = (
+  error: Error,
+  ctx?: IRequestContext,
+): ProblemDetails => buildProblemDetails(error, ctx, resolveRfc7807Type);