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.
| Jay Pipes (jaypipes) wrote | #1 |
| summary: |
- The way glance passes exceptions to the client needs to be completely - re-evaluated + Glance should ensure consistency in exception messages all the way to + client |
| Changed in glance: | |
| status: | New → Incomplete |
| status: | Incomplete → Confirmed |
| importance: | Undecided → Medium |
| status: | Confirmed → Triaged |
| 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 |
| Tom Fifield (fifieldt) wrote | #2 |
| Changed in glance: | |
| status: | Triaged → Incomplete |
| Erno Kuvaja (jokke) wrote | #3 |
| Changed in glance: | |
| status: | Incomplete → Invalid |
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