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

Better error handling #509 #528

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

whysage
Copy link
Contributor

@whysage whysage commented Nov 1, 2021

Add providers log on error.

Add providers log on error.
@whysage whysage changed the title #509 Better error handling #509 Nov 1, 2021
@whysage
Copy link
Contributor Author

whysage commented Nov 1, 2021

@rmk135
Please review PR.
I'll not sure about it.


Here - #510 - you write that after reraise exception all exceptions will be just general 'Exception'.
I test my code by adding addition try here
src/dependency_injector/providers.pxd
line 582
try: return call(*args, **kwargs) except Exception as exception: raise exception

and receive type of Exception was TypeError (I used this demo
https://github.com/ets-labs/python-dependency-injector/blob/master/examples/demo/with_di.py
without env var timeout - so error was - TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType')


Also, I'm not sure about printing providers, Maybe we can log them somewhere.
Please advise.

Addition idea about problem was to add ENV var like DEPENDENCY_INJECTION_DEBUG_MODE
and print called providers only it is enabled.

I think this issue is very important - for me, it is real hell to find error in dozens providers by unclear error message.
Please help :-)

@rmk135 rmk135 self-assigned this Nov 1, 2021
try:
result = self._provide(args, kwargs)
except Exception as exc:
print(self)
Copy link
Member

Choose a reason for hiding this comment

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

I'm not quite sure about using print() here. It will send some data to stdout, which might not always be the desired behavior.

The idea, generally, looks interesting. Maybe we can use the logging module?

Copy link
Contributor

Choose a reason for hiding this comment

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

I would agree with @rmk135 to use the logging module with logger.exception with some extra useful messages as it allows users to have more control on the output through logging.config. Meanwhile, I believe the LogRecord may not provide precise info given the cython context (caller line number, stacktrace etc.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for reply!

@rmk135 @gen-xu

Please look at updated pull request.
I hope logging.debug() is good idea because, by default, we have warning log level, and I hope no one use debug level in production) - so nothing will change for current users until logging level set to debug.
If this request will be accepted - I'll add article to documentation about this.

Use logging for providers error.
@whysage
Copy link
Contributor Author

whysage commented Nov 20, 2021

Hi
@rmk135 @gen-xu
Any updates?

@whysage
Copy link
Contributor Author

whysage commented Dec 5, 2021

Hi!
@rmk135 @gen-xu
ping for updates)

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.

None yet

3 participants