Early return of a Template

[szabgab]

I seem to have many cases when in the route I need to check certain things, if they fail I might want to return an error message and only if all of them passed I would do some more processing. I included a minimal example where I know I could have just defined the expected parameter to be u32, but it seems to a simple example.

In the first implementation (called deep) I'd check each condition with a match and in the Ok arm I'd go deeper and deeper. Not nice.

The second implementation (early return using match) looks better but I feel I still have lots of unnecessary code.

In the 3rd implementation I return a Result<Template, Template>.

I wonder if this seems like a correct way to handle the situation or if there is a better way?

#[macro_use]
extern crate rocket;

use rocket_dyn_templates::{context, Template};

#[get("/")]
fn index() -> Template {
    Template::render("index", context! {
    })
}

// deep
#[get("/number/<number>")]
fn number(number: &str) -> Template {
    match number.parse::<i32>() {
        Ok(number) => {
            // lots of processing with number
            Template::render("number", context! { number })
            
        },
        Err(err) => Template::render("message", context! { message: format!("not a number {err}") }),
    }
}


// early return using match
#[get("/number/<number>")]
fn number(number: &str) -> Template {
    let number = match number.parse::<i32>() {
        Ok(number) => number,
        Err(err) => return Template::render("message", context! { message: format!("not a number {err}") }),
    };

    // lots of processing with number
    Template::render("number", context! { number })
}


#[get("/number/<number>")]
fn number(number: &str) -> Result<Template, Template> {
    let number = number.parse::<i32>().map_err(|err| 
           return Template::render("message", context! { message: format!("not a number {err}") }))?;

    // lots of processing with number
    Ok(Template::render("number", context! { number }))
}



#[launch]
fn rocket() -> _ {
    rocket::build()
        .mount("/", routes![index, number])
        .attach(Template::fairing())
}

#[cfg(test)]
mod tests;

[edgarogh]

You can implement you own custom responder around Template.

#[derive(Responder)]
#[response(status = 400)] // That will depend on your use-case
struct ErrorTemplate(Template);

Then implement From<E> where E is your error type..

impl From<ParseIntError> for ErrorTemplate {
    fn from(err: ParseIntError) -> Self {
        Self(Template::render("message", context! { message: format!("not a number {err}") })))
    }
}

You can do this for multiple errors, but be consistent with the HTTP status code you chose previously. If you want to support multiple status codes, add a field to ErrorTemplate to store the status code, and implement Responder yourself instead of deriving it (so that it's not static).

---

This ultimately allows you to use the try (?) operator to convert your error to your ErrorTemplate.

#[get("/number/<number>")]
fn number(number: &str) -> Result<Template, ErrorTemplate> {
    let number = number.parse::<i32>()?;
    Ok(Template::render("number", context! { number }))
}

This is how I always do my error management with Rocket.

[the10thWiz]

I do something similar, but I use an enum to avoid implementing Responder directly.

#[derive(Responder)]
pub enum ApiResponse<T> {
   Ok(T),
   #[response(status = 400)]
   BadRequest(Template),
   #[response(status = 401)]
   Unauthorized(Template),
}

This has the same effect, but simplifies code, and ApiResponse could implement From<Result<T, Error>> to simplify constructing the associated Template.

[edgarogh]

The issue with this is that you can't use the try operator. I'd rather recommend turning your ApiResponse enum into an ApiError enum without the Ok(T) variant, and have the handler return Result<T, ApiError>

[the10thWiz]

It is possible to implement try with nightly, but you're correct. In principle, you could create multiple error enums, to indicate which errors a specific route might return (which would improve something like openapi documentation), but I don't think it's likely worth the extra effort.