Glance should ensure consistency in exception messages all the way to client
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Glance |
Invalid
|
Wishlist
|
Unassigned |
Bug Description
There is a systemic problem with the way Glance handles exceptions passed from underlying API and backend code to its client. The current model goes something like this:
1. Error happens.
2. Catch it, and log it.
3. Re-raise a different exception with no message, failing preserving either the message or traceback.
4. Allow client to transform neutered exception into an even-more-generic HTTP status code.
A perfect example of this is here: https:/
In that code, a very useful error message is logged with a very meaningful exception class, and then replace by a blank HTTPForbidden, which returns to the client as a 403 with no information.
This has lead to many hours of wasted developer time on bugs like https:/
This entire behavior needs to be re-thought and re-worked so that consumers of Glance's client can provide useful, meaningful experiences without spending hours digging through Glance's codebase.
Changed in glance: | |
assignee: | nobody → Brian Rosmaita (brian-rosmaita) |
status: | Triaged → In Progress |
Changed in glance: | |
importance: | Medium → Wishlist |
status: | In Progress → Triaged |
assignee: | Brian Rosmaita (brian-rosmaita) → nobody |
I agree that more consistency should be used in how exceptions are handled in the controllers and how the client receives (and reraises non-HTTP exceptions.
Not sure I buy that the entire system needs to be overhauled though... and so I've changed the bug description accordingly.
best,
-jay