-
Notifications
You must be signed in to change notification settings - Fork 32
Description
As suggested by @pcrespov in #7810 :
I can definitely see the purpose of your handler—it’s nicely self-contained, which makes it easy to revisit later and integrate with the rest of the system.
That said, I’m wondering how it aligns with the overall error-handling logic, especially what's implemented in exceptions.service_error_utils.py. For example, there are certain assumptions made there about error handling (e.g., by @bisgaard-itis) that may not be fully reflected here. I'm curious how all of these pieces fit together.
The broader error-handling approach is still heavily under development since we were diverging in style and purpose (see https://github.com//issues/2446), but I’m a bit concerned that we might start to diverge again.
Would it make sense to take a step back and review the entire mechanism? It might be worth aiming for a unified approach that we can apply consistently, rather than introducing new handlers with separate logic.
Another see it would be nice e.g. is to also advertise these status code automatically in the routes decorators so they appear in the openapi specs.