search

python / asyncio

asyncio historical repository
https://docs.python.org/3/library/asyncio.html
1.03k stars 178 forks source link

BaseSubprocessTransport can raise in __del__ #473

Open Tinche opened 7 years ago

Tinche commented 7 years ago

What's our policy on raising exceptions in destructors?

For example, this code: https://github.com/python/asyncio/blob/ab113e4f5c437c3a85abfb4be6cf6c22f6f68b9e/asyncio/base_subprocess.py#L131 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.

Martiusweb commented 7 years ago

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.