Trait IntoError 

pub trait IntoError: Display {
    // Provided methods
    fn status(&self) -> StatusCode { ... }
    fn message(&self) -> String { ... }
}

Let a user error type be returned from a handler with ?.

Result<T> already flows through ? for Churust’s own Error, but a handler holding a Result<T, sqlx::Error> previously needed a map_err at every call site. Implement this and the conversion is automatic.

use churust_core::IntoError;
use http::StatusCode;

#[derive(Debug)]
struct NotFound;
impl std::fmt::Display for NotFound {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "no such row")
    }
}
impl IntoError for NotFound {
    fn status(&self) -> StatusCode { StatusCode::NOT_FOUND }
}

fn find() -> Result<&'static str, NotFound> { Err(NotFound) }

fn handler() -> churust_core::Result<&'static str> {
    Ok(find()?)   // converts through IntoError
}
assert_eq!(handler().unwrap_err().status(), StatusCode::NOT_FOUND);

Why message does not default to Display

It would be convenient and it would leak. Error types routinely render connection strings, file paths and query fragments in their Display, and a framework that forwarded those to clients by default would turn every adopter’s first ? into an information disclosure. The default is the status’ canonical reason; opting into detail is safe, opting out of a leak is not.

Provided Methods

fn status(&self) -> StatusCode

The status this error should produce. Defaults to 500.

fn message(&self) -> String

The client-facing message. Defaults to the status’ canonical reason, deliberately not Display — see the note on the trait.

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors