You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 23, 2017. It is now read-only.
can potentially throw if the event loop as been closed already (or for any unforeseen reason, really). I've had this happen to me while testing a piece of asyncio code, with the exception coming up ten tests later.
Shouldn't this be wrapped in a try/except, and the exception just logged, not propagated? We generally can't know when a destructor will be triggered.
I can put together a small pull request if that's ok.
The text was updated successfully, but these errors were encountered:
An exception which raises outside a destructor is printed to stderr ("Exception ignored in:"...).
In this case, while it's probably not easy to understand the source of the exception, I think it's better to let the exception be printed: it tells that the object should have ben closed explicitly before being destroyed. It also tells that this must be done while the loop to which the object is bound is still ready in order to be able to correctly close the object.
However, if you see "Exception ignored in:" without more details, it's probably an exception in the repr method of the object, and this one should be fixed because it silences the actual exception.
What's our policy on raising exceptions in destructors?
For example, this code:
asyncio/asyncio/base_subprocess.py
Line 131 in ab113e4
Shouldn't this be wrapped in a try/except, and the exception just logged, not propagated? We generally can't know when a destructor will be triggered.
I can put together a small pull request if that's ok.
The text was updated successfully, but these errors were encountered: