Message226995
| Author |
vstinner |
| Recipients |
gvanrossum, oconnor663, vstinner, yselivanov |
| Date |
2014年09月17日.11:59:25 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1410955165.4.0.0859695632084.issue22428@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I see different issues in your example:
* If the coroutine raises an exception which doesn't inherit from Exception (but inherits from BaseException), run_until_complete() doesn't consume the exception from the temporary task object
=> run_until_complete(coroutine) sets the _log_destroy_pending attribute of the temporary Task to False, but this attribute controls the "Task was destroyed but it is pending!" warning. The "%s exception was never retrieved" warning is controlled by the Future._log_traceback attribute (in Python 3.4+). This attribute is set to True in Future.set_exception().*
* If a Task is deleted late during Python shutdown, the logging module fails to log the traceback because the builtin function has been deleted.
=> IMO it's an issue in the traceback module. It may catch the AttributeError on the call to linecache.getline(). It's not convinient to get a new exception (traceback) when trying to display a traceback... Maybe the traceback can check if Python is exiting before calling the linecache module?
* If you call again loop.run_forever(): it exits immediatly because a call to loop.stop() was scheduled by future.set_exception()
=> I created the issue #22429
I don't think that it's a bug that Task._step() calls set_exception() for BaseException. Otherwise, how do you know that a task failed? |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2014年09月17日 11:59:25 | vstinner | set | recipients:
+ vstinner, gvanrossum, yselivanov, oconnor663 |
| 2014年09月17日 11:59:25 | vstinner | set | messageid: <1410955165.4.0.0859695632084.issue22428@psf.upfronthosting.co.za> |
| 2014年09月17日 11:59:25 | vstinner | link | issue22428 messages |
| 2014年09月17日 11:59:25 | vstinner | create |
|