refactor: better errors #1783
refactor: better errors #1783
Conversation
Adds extension methods to make ApiErrors directly from `Result` or `Option`s.
| @@ -80,6 +82,131 @@ impl ApiError { | |||
| } | |||
| } | |||
|
|
|||
| pub trait ErrorContext<T> { | |||
There was a problem hiding this comment.
What do you think of having a generic context_error(self, message: &str, status_code: StatusCode) (and the corresponding with variant) instead of dedicated method each time ?
There was a problem hiding this comment.
Nah, then each caller would have type out the status code each time. Not a fan of passing booleans as args to functions and this seems close to the same thing.
There was a problem hiding this comment.
We could also have the generic one, and implement the other one using it. This wouldn't constraint the users to use the select few status code implemented. And I'm not sure I see how passing boolean can be compared to passing a StatusCode enum variant 🤔
There was a problem hiding this comment.
That's an idea, but I cannot abstract it more though. Ie I won't be able to make them use the generic one since they log different warn! and error!.
I mean they are the same in that they use a dynamic control (the args) when we know which concrete type we want when we write the code. So their dynamic nature at runtime feels the same.
There was a problem hiding this comment.
Ah, make sense. Ok let's keep it that way for now then, we'll see when the need arise.
Description of change
Improve
ApiErrorto make error handling on headroom easierHow has this been tested? (if applicable)
Na