Actix Error is Actix Web’s general-purpose error type for handler and application failures. A handler can return Result<HttpResponse, Error>; the ? operator converts compatible Rust errors into Actix Error, which Actix Web converts into an HTTP response for the client. section 5.2
A typical failure path uses:
- Result to represent successful and failed operations. section 5.2
- The ? operator to propagate failures without matching every Result variant. section 5.2
- Built-in From implementations to convert standard-library errors into Actix Error. section 5.7
- ResponseError and custom error types when applications need meaningful, domain-specific HTTP responses. section 5.7
Propagating a file failure from a handler
An async hello handler can open a file with File::open("fictionalfile.txt")? and otherwise return HttpResponse::Ok. If the file is missing, the propagated I/O error becomes an HTTP error response instead of requiring an explicit match. section 5.2
Custom errors in a course API
A database function returns Result<Course, EzyTutorError>, while the route returns Result<HttpResponse, EzyTutorError>. The route maps a successful course to JSON, and Actix Web converts failures through the custom error implementation. section 5.7 section 5.6
use actix_web::{error::Error, web, App, HttpResponse, HttpServer};
async fn hello() -> Result<HttpResponse, Error> { #1
Ok(HttpResponse::Ok().body("Hello there!")) #2
}
#[actix_web::main]
async fn main() -> std::io::Result<()> {
HttpServer::new(|| App::new().route("/hello", web::get().to(hello)))
.bind("127.0.0.1:3000")?
.run()
.await
}
Shows the minimal Actix handler signature, successful response, application setup, and route registration. section 5.2
