-
Notifications
You must be signed in to change notification settings - Fork 142
Return Flask errors as JSON instead of HTML (mentioned in issue #561) #567
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,7 @@ | ||
from os import getenv | ||
|
||
from flask import Flask | ||
from flask import Flask, jsonify | ||
from werkzeug.exceptions import HTTPException | ||
|
||
from env import load_app_env | ||
|
||
|
@@ -36,5 +37,19 @@ | |
configure_db_with_app(app) | ||
initialize_database(app) | ||
|
||
def handle_exception(e): | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @dominicghizzoni I agree with @thesujai here. The code is 50% there. I would suggest going through this doc: After going through these and the example you would have an idea of what kind of a code. |
||
if isinstance(e, HTTPException): | ||
return jsonify({ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem with error JSON is that it’s not compatible (or generalized) for JavaScript, which is the client for the backend. Instead, we should only return:
We don’t want to expose the user to details about the server-side error. Providing a detailed description could be a security risk, as it may reveal internal information about our code.(feels weird talking about code revealing to user, when the whole code is OS 😅) I am just saying again this hander is not supposed to handle errors < 500(status code) because they should be dealt with assertion, if-else, try-catches, or middleware(Its more of a developer's responsibility when shipping features) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @thesujai I think there is value in telling the client "the id you requested data for does not exist, hence a 404". It might be hidden from the user via the next js bff handling. This backend should also be usable as a standalone analytics/data service if needed. Also, a generic 500 makes the API hard to debug. Please let me know if I misunderstood this comment. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @thesujai thanks alot for reviewing this code beforehand and linking the documentation. Really appreciate it 🙌 |
||
"error": e.name, | ||
"description": e.description, | ||
"status_code": e.code | ||
}), e.code | ||
|
||
return jsonify({ | ||
"error": "Internal Server Error", | ||
"description": str(e), | ||
"status_code": 500 | ||
}), 500 | ||
|
||
if __name__ == "__main__": | ||
app.run(port=ANALYTICS_SERVER_PORT) |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The handler is implemented well(needs a little tweak), but we need to let the flask know that this is the Error Handler it should be using for unhandled errors(Because flask returns with HTML Content when an unexpected/unhandled error occurs)
Check this: https://flask.palletsprojects.com/en/2.3.x/errorhandling/#registering
so adding something like below to
app
should suffice:app.register_error_handler(Exception, handle_exception)