Open jotaen4tinypilot opened 2 years ago
It’s also worth keeping in mind that we don’t rely on HTTP status codes that much anyway, but we assign string codes in case we need to distinguish errors in the frontend.
So a refactoring like this would be mostly for code sanity, not so much for improved functionality.
In https://github.com/tiny-pilot/tinypilot-pro/pull/364#pullrequestreview-862312155 the idea came up to centralize the error handling of the API layer in the backend. Currently, we need to write the same
try
/except
all over again, but the only reason we do this is for assigning HTTP status codes.Example: In the Pro
api.py
, we catch 17×request_parsers.errors
and then return status400
. Then there are an additional 34× where we have anexcept
block that maps to a specific error code.I’d spontaneously see multiple ways how we could do this: (there might be others/more)
api.py
, since we wouldn’t need anytry
/except
at all.We could probably also do that less fancy as function call in the method body directly.
request_parsers.errors.Error
, and I’ve demonstrated it in this quick POC).500
we do have that already).Not sure how much effort this is worth investing in. On the other hand, out current approach is indeed quite verbose/repetitive for no real “benefit”, and
api.py
continues to grow.