-
Notifications
You must be signed in to change notification settings - Fork 696
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
Coroutine sink exceptions are not caught #227
Comments
Hey @gdmoore, thanks for the bug report! The first thing, I think, it that you should await |
Sorry, made that mistake when minimizing it for the bug report. In my actual app I am awaiting before my app shuts down. Here's a better example which runs for 5 seconds, doing the same as above, and finishing with a
here's the output I get:
... etc, 5 times total. Each call to my sink which raises an exception never has the exception retrieved, even if the program ultimately finishes with a call to It seems like the Future returned by the sink coroutine isn't being held onto by loguru when it invokes all of the sinks. Or if it is, doing it in |
Thanks for the update! So it's going to be a little more complicated than I thought... 😬 Loguru manages coroutines similarly to |
I don't think the approach with If I have a long-running program with a sink that sometimes fails, you'll be storing all the failures in memory for weeks or months, and I won't get any notification that there were failures until the program is shutting down. I think this would be surprising behaviour. I think I think you need to do something like the following. If anyone passes a coroutine to If |
Yes, you are right. I realized later that it was not a good solution to store pending tasks. However, I'd rather not use a thread to fix this. What about |
A thread is definitely an ugly solution. That looks a lot better. You're right about propagation. I was kind of thinking of it in terms of the unhandled exception being raised to the call site (eg the person who called Printing in the done callback if
|
Great, so we agree on how this should behave. 👍 I'm a little worried about the callback overhead but I don't see any other simple solution. |
Fixed in next version. :) |
It appears that if you use a coroutine as a sink and it has an unhandled exception, even with
catch=True
specified inadd()
, the exception is not caught, and you will get aTask exception was never retrieved
error on stderr from asyncio: https://docs.python.org/3/library/asyncio-dev.html#detect-never-retrieved-exceptions2020-03-23 12:31:58.236 | INFO | main:main:3 - hello world
Task exception was never retrieved
future: <Task finished name='Task-2' coro=<sink() done, defined at :1> exception=Exception('oh no')>
Traceback (most recent call last):
File "", line 2, in sink
Exception: oh no
The text was updated successfully, but these errors were encountered: