Enum ApiError 

pub enum ApiError {
    NotFound(String),
    BadRequest(String),
    Unauthorized(String),
    Forbidden(String),
    TooManyRequests(String),
    Validation(WriteError),
    Database(Error),
    Internal(String),
}

A handler-facing error. Build explicit ones with the constructors, or let ? convert an ORM error (sqlx::Error / WriteError / DynError).

Variants

NotFound(String)

404 — ApiError::not_found.

BadRequest(String)

400 with a single message — ApiError::bad_request.

Unauthorized(String)

401 — no credentials, or credentials that resolved to nobody (gaps3 #62).

Its absence is why real handlers kept hand-rolling (StatusCode, String): a login-gated page needs a 401, ApiError could not express one, so the whole handler fell back to the tuple — and the tuple’s 500 arm is err.to_string(), which puts the database’s own error text on the page. A missing variant is not a cosmetic gap; it pushes people onto the leaky path.

Forbidden(String)

403 — authenticated, but not allowed.

TooManyRequests(String)

429 — rate-limited.

Validation(WriteError)

400 carrying a structured validation failure (per-field + non-field).

Database(Error)

500 — a database error. Logged server-side; the client sees an opaque “internal server error” (WEB-5: never leak DB internals).

Internal(String)

500 — any other internal error — ApiError::internal. Logged; opaque.

Implementations

impl ApiError

pub fn not_found(msg: impl Into<String>) -> Self

A 404 Not Found with a client-visible message.

pub fn unauthorized(msg: impl Into<String>) -> Self

A 401 Unauthorized with a client-visible message.

pub fn forbidden(msg: impl Into<String>) -> Self

A 403 Forbidden with a client-visible message.

pub fn too_many_requests(msg: impl Into<String>) -> Self

A 429 Too Many Requests with a client-visible message.

pub fn bad_request(msg: impl Into<String>) -> Self

A 400 Bad Request with a client-visible message.

pub fn internal(msg: impl Into<String>) -> Self

A 500 whose message is logged server-side but never sent to the client.

Trait Implementations

impl Debug for ApiError

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Display for ApiError

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Error for ApiError

fn source(&self) -> Option<&(dyn Error + 'static)>

Returns the lower-level source of this error, if any.

fn description(&self) -> &str

👎Deprecated since 1.42.0:

use the Display impl or to_string()

fn cause(&self) -> Option<&dyn Error>

👎Deprecated since 1.33.0:

replaced by Error::source, which can support downcasting

fn provide<'a>(&'a self, request: &mut Request<'a>)

🔬This is a nightly-only experimental API. (error_generic_member_access)

Provides type-based access to context intended for error reports.

impl From<DynError> for ApiError

fn from(e: DynError) -> Self

Converts to this type from the input type.

impl From<Error> for ApiError

fn from(e: Error) -> Self

Converts to this type from the input type.

impl From<TemplateError> for ApiError

gaps3 #57 — so umbral::templates::render(...)? works with a bare ?.

Rendering a template is the single most common fallible line in an HTML handler, and without this impl ApiError could not be that handler’s error type at all. Which is how every example ended up hand-rolling fn internal_error(e) -> (StatusCode, String) — and that helper hands e.to_string() straight to the browser, so a missing table or a bad column name is printed to whoever asked for the page.

A broken template is a bug in the app, never in the request: it becomes an opaque 500 with the real cause logged server-side, the same posture as a database error.

fn from(e: TemplateError) -> Self

Converts to this type from the input type.

impl From<WriteError> for ApiError

fn from(e: WriteError) -> Self

Converts to this type from the input type.

impl IntoResponse for ApiError

fn into_response(self) -> Response

Create a response.