How can response::status::BadRequest be caugth?

[Quba1]

Guide suggests the a possible (recommended) way to handle errors is by returning Result with error type that implements Responder, as show here. As I understand, the outcome should then be Error and response should be generated with a catcher.

However, this doesn't work if Error is one of the response::status structs, even though they implement Responder.

This example presents the issue:

use rocket::{response::status::BadRequest, http::Status};

#[macro_use]
extern crate rocket;

#[catch(400)]
fn bad_request() -> &'static str {
    "Bad Request! :("
}

#[get("/")]
fn index() -> Result<&'static str, BadRequest<String>> {
    Err(BadRequest("Terrible Request!".to_string()))
}

#[get("/")]
fn duo() -> Result<&'static str, Status> {
    Err(Status::BadRequest)
}

#[launch]
fn rocket() -> _ {
    rocket::build()
        .mount("/", routes![index])
        .mount("/duo", routes![duo])
        .register("/", catchers![bad_request])
}

Requesting /duo gives and error outcome and catcher generates the response

GET /duo text/html:
   >> Matched: (duo) GET /duo/
   >> Outcome: Error(400 Bad Request)
   >> Responding with registered (bad_request) 400 catcher.
   >> Response succeeded.

But when requesting / outcome is success and content is generated from the field inside BadRequest

GET / text/html:
   >> Matched: (index) GET /
   >> Outcome: Success(400 Bad Request)
   >> Response succeeded.

So, what am I doing wrong here? How can I make outcome be error and thus catch BadRequest with the field inside it, to customize for example how the error page looks?

[SergioBenitez]

The docs for each type's Responder impl should clarify what's happening:

• BadRequest
• Status

In short: BadRequest does not forward (it just sets the status code for the inner response) while Status does.

[Quba1]

The Status docs indeed say that it forwards to a catcher, but BadRequest has only a default description of impl Responder, which technically should also forward to appropriate catcher as long as Err(Status) is returned:

fn respond_to(self, request: &'r Request<'_>) -> Result<'o>
Returns Ok if a Response could be generated successfully. Otherwise, returns an Err with a failing Status.
The request parameter is the Request that this Responder is responding to.
When using Rocket’s code generation, if an Ok(Response) is returned, the response will be written out to the client. If an Err(Status) is returned, the error catcher for the given status is retrieved and called to generate a final error response, which is then written out to the client.

In the code of respond_to(), Status explicitly returns Err for non-success status codes:

// rocket/response/responder.rs:535

  fn respond_to(self, _: &'r Request<'_>) -> response::Result<'static> {
      match self.class() {
          StatusClass::ClientError | StatusClass::ServerError => Err(self),

While BadRequest return Ok irregardless of status code:

// rocket/response/status.rs:236

impl<'r, 'o: 'r, R: Responder<'r, 'o>> Responder<'r, 'o> for Custom<R> {
    #[inline]
    fn respond_to(self, req: &'r Request<'_>) -> response::Result<'o> {
        Response::build_from(self.1.respond_to(req)?)
            .status(self.0)
            .ok()

And as far as I understand that means that BadRequest can't never go to catcher. Do I understand correctly that's because response::Result can only Status for Err, so that additional information from BadRequest would be lost?

[SergioBenitez]

I think there's a fundamental misunderstanding with respect to error catchers. Error catchers react to failures at the routing level, not to responses with a failing status code. A response with a failing status code is just that and only that: an HTTP response with a status code >= 400.

Error catchers catch failures at the routing level. Those failures are also marked with a status code, but there is no associated HTTP response with that status code: it merely indicates the kind of routing error that occurred and is used to route the error to the appropriate catcher. It may also provide a hint towards the kind of HTTP response that should be generated as a result of the routing failure, but that is orthogonal to the error catcher and the original status code. These routing failures can be signaled by different parts of the application including request guards and responders. For a responder to signal a failure, it returns an Err.

Here, we see two responders doing different things. The Status responder signals a routing error when the status is >= 400. This results in the corresponding error catcher to be invoked. The BadRequest responder never indicates a routing error however. It instead always generates a valid HTTP response (Ok) with the associated status. Thus no error catcher will ever be invoked. There's no information being lost, it's simply not what its functionality is. And while you're right that this isn't indicated in its Responder impl docs, it is indicated in the type's docs, since the type only exists to be used as a responder.

I hope this provides clarity.

[Saplyn]

Thanks for this post and answer! This helped me a lot.

I think there's a fundamental misunderstanding with respect to error catchers. Error catchers react to failures at the routing level, not to responses with a failing status code. A response with a failing status code is just that and only that: an HTTP response with a status code >= 400.

I found this to be an easy misunderstanding (at least to me). The catcher arise condition "failing responder" in documentation and the guide both sounds like "a response with error status code".

Also, the error-handling example further "strengthens" my misunderstanding, because the handler ...

#[get("/<code>")]
fn forced_error(code: u16) -> Status {
    Status::new(code)
}

... which looks like "a response with error status code". I understand that this may be a design choice, but I was actually confused by it.

Perhaps we should add this to the FAQ list? Or point it out or clarify this in the documentation?