You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Finally we could explore ideas even further on error handling to enable, besides the general catchers, route level catchers that might be defined on the handler level:
This looks related to #749: in short, we do want some sort of type-based error catching but there are some issues to work out. Therefore, I'm closing this issue in favor of discussing further there.
Please let me know how feasible this sounds and any thoughts around it.
I believe this is the first time I have seen a proposal for catching individual variants of enums instead of entire types. Since we need per-type catchers in order to implement per-variant catchers, I think this particular feature is a bit less likely / farther off.
Hi!
It'd be convenient to have a more idiomatic way to define error catchers by a custom error type or enum member.
For example for an application with a couple handlers defined like
It could be possible to have general catchers for
CustomErrorEnum::Variant1
andCustomErrorEnum::Variant2
defined withIt'd fall back to the current
Err(_)
handling for the error types without a catch definition.Then, it could be possible to catch the inner error data so that responders can be easily implemented for particular error types:
Additionally, with this in place it could be easy to define some helper macros to enable something like this to easily define catchers:
Finally we could explore ideas even further on error handling to enable, besides the general catchers, route level catchers that might be defined on the handler level:
I think this would make it easier to separate concerns in handlers and would improve rocket ergonomics in error handling.
Please let me know how feasible this sounds and any thoughts around it.
The text was updated successfully, but these errors were encountered: