triceratops-project / triceratops

1 stars 0 forks source link

Error handle requests #3

Open FelixKLG opened 7 months ago

FelixKLG commented 7 months ago

Requests should not need to employ unwrap() or expect() anywhere; sufficiently flesh out app to the point where errors can be handled with map_err(|_| T) and provide sufficient ergonomics to not impede development or create overly verbose code.

FelixKLG commented 7 months ago

I made a ResponseError enum which impls IntoResponse, most common error codes are contained within it. It also requires a generic of T which impls IntoResponse as well. Can be used for Json some other format which can relay some info.

Example:

let my_env_var = env::var("EXAMPLE")
.map_err(|| ErrorResponse::InternalServerError(Json(json!({"message": "Internal Server Error"}))))?;

The issue here, is that it's very long and verbose to add the additional parameter. I might make some types not accept a message like InternalServerError and just return a standardised message. Or make the T param inside the ErrorResponse Option<T>, there could be a function which returns a default error code and a function which accepts a custom response.

Something like this:

impl<T: IntoResponse> ErrorResponse<T> {
    pub fn conflict() -> Self {
        Self::Conflict(None)
    }

    pub fn conflict_with_response(inner: T) -> Self {
        Self::Conflict(Some(inner))
    }
}
FelixKLG commented 7 months ago

To tack on some other ideas, how good/bad of an idea would it be to have some kind of struct in the AppState which contained a bunch of enums and functions with shit like Sentry or some logger embedded into it. That means it's a TONNE easier to handle logging later on down the line.

FelixKLG commented 5 months ago

So recently I've been working on different projects which I did the error handling better from the start, this is such a fucking mess; most of the code will need to be jiggled around a decent amount and split out in a way that makes sense.

I want the helper functions for converting errors because without them it's just so painful to do this, also the error responses should default to JSON always because of how the system is gonna work from now on so I don't need to faff around with generics and other crap.