BaseSubprocessTransport can raise in del

What's our policy on raising exceptions in destructors?

For example, this code:

Line 131 in ab113e4

self.close()

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.

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.