Logging exceptions rework #5118
Conversation
Ugh. This makes it much harder to review. Let's not do that until the entire codebase is linted. |
readthedocs/projects/tasks.py
Outdated
| ) | ||
| return False | ||
|
|
||
|
|
||
| # Exceptions under ``throws`` argument are considered ERROR from a Build | ||
| # perspective but as a WARNING for the application itself. These exception are | ||
| # logged as ``INFO`` and they are not sent to Sentry. |
There was a problem hiding this comment.
I don't understand this comment. "considered ERROR from a Build
perspective but as a WARNING for the application itself" -- what does that mean in practice? Does the build stop?
There was a problem hiding this comment.
A known error "by RTD's code" like "we didn't find the requirements.txt you configured in the YAML file" is an ERROR that will make the build to stop. It's an error from the user's perspective.
Although, it's just a WARNING from the developer's perspective or the application (RTD's code) itself.
The build stops and the exception is logged as INFO/WARNING not as an ERROR.
If you have a better way to explain this we can adapt the comment. I'd appreciate.
These exceptions won't be logged into Sentry as ERROR but they will be logged as INFO since they are errors from a user's perspective (build failed) but not from an application perspective (our code didn't fail).
Depending on the exception, we want to log at different levels and in all the cases stop the build (execute `raise` again).
humitos
force-pushed
the
humitos/logging-exceptions-rework
branch
from
30885b3 to
1176c71
Compare
delete-merged-branch
bot
deleted the
humitos/logging-exceptions-rework
branch
This PR,
setup_vcsand it raises an exception without stopping the build processBuildEnvironmentWarningfromTask.throwsargument in tasks that is not neededupdate_docstasks to not log them in Sentry as ERRORpre-commitCloses #5114
Closes #3856
Closes #4978
Related #5073
Related #5115