Skip to content
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

WIP: Handle Logger.exception() outside "except" block #635

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

sscherfke
Copy link
Contributor

Fixes: #634

Summary

Pull Request Check List

  • Do not open pull requests from your main branch – use a separate branch!
    • There's a ton of footguns waiting if you don't heed this warning. You can still go back to your project, create a branch from your main branch, push it, and open the pull request from the new branch.
    • This is not a pre-requisite for your your pull request to be accepted, but you have been warned.
  • Added tests for changed code.
    • The CI fails with less than 100% coverage.
  • New APIs are added to our typing tests in api.py.
  • Updated documentation for changed code.
    • New functions/classes have to be added to docs/api.rst by hand.
    • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.
      • The next version is the second number in the current release + 1. The first number represents the current year. So if the current version on PyPI is 23.1.0, the next version is gonna be 23.2.0. If the next version is the first in the new year, it'll be 24.1.0.
  • Documentation in .rst and .md files is written using semantic newlines.
  • Changes (and possible deprecations) are documented in the changelog.
  • Consider granting push permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.

Comment on lines 645 to 646
if exc_info:
if exc_info != (None, None, None):
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like this was the actual bug, right? because a negative result from _figure_out_exc_info isn't falsey

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, more or less. The (None, None, None) case was handled elsewhere (surprisingly, from a typing perspective ;-)), but it only worked for the default exception formatter.

_figure_out_exc_info(exc_info)
)
exc_info = _figure_out_exc_info(event_dict.pop("exc_info", None))
if exc_info != (None, None, None):
Copy link

@raqbit raqbit Jul 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like this would pass any None/Falsy exc_info in the event dict into the formatter. Is this expected?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed it to if exc_info and exc_info != (None, None, None). This should work.

Not happy though, that exc_info can be literally anything. I will take a look if this can somehow be changed/improved.

assert {"exception": "MISSING"} == format_exc_info(
None, None, {"exc_info": ei}
)
assert {} == format_exc_info(None, None, {"exc_info": ei})
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this okay for you, @hynek ? The format_exc_info() handled the (None, None, None) (even though its signature suggested that exc_info: ExcInfo) and returned {"excepiton": "MISSING"}.

Now, (None, None, None) will no longer be passed to it and thus there will no longer be a MISSING.

The main problem of the function is that *v* can really be anything
(depending on what the users) do and the annotated return type did not
properly match it (e.g., if *v* was "0", the return value would be "0").

The function now rigorously checks the user input and either returns
the desired result (an exc info tuple) or None.  This makes it easier
and safer to use this function.
@sscherfke
Copy link
Contributor Author

sscherfke commented Jul 26, 2024

I think that 0c02f29 really fixes the problem in the right way. I added a longer description to the commit to explain why.

Let me know, what you think :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ExceptionRenderer w/ ExceptionDictTransformer unable to handle exception log outside exception handler
3 participants