On Mon, Feb 25, 2019 at 4:15 PM Josh Quigley <0zeroth@gmail.com> wrote:
I've realised the error of my ways: because Task separates the scheduling from the response handling, you cannot know if an exception is unhandled until the task is deleted. So in my example the reference means the task is not deleted, so the exception is not yet unhandled.
This is in contrast to APIs like call_soon(callable, success_callback, error_callback) where there the possibility of delayed error handling is not present. In that case the loop can reliably crash if either callback raises an exception.
So, the 'solution' to this use-case is to always attach error handers to Tasks. A catch-all solution cannot catch every error case.
That's right. There are other ways to structure async code to avoid running into these cases, that are implemented in Trio, and there are discussions happening (slowly) about adding them into asyncio as well. See: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-cons... Also, I could swear I saw some library that tried to implement nurseries on asyncio, but I can't find it now... :-/ maybe someone else here knows? -n -- Nathaniel J. Smith -- https://vorpus.org