Open FelixKLG opened 9 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))
}
}
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.
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.
Requests should not need to employ
unwrap()
orexpect()
anywhere; sufficiently flesh out app to the point where errors can be handled withmap_err(|_| T)
and provide sufficient ergonomics to not impede development or create overly verbose code.