Re: [Async-sig] Reliably make unhandled exceptions crash the event loop
Maybe this one https://github.com/malinoff/aionursery ? On 26/02/19 02:14, Nathaniel Smith wrote: On Mon, Feb 25, 2019 at 4:15 PM Josh Quigley <0zer...@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-considered-harmful/ 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 ___ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [Async-sig] Reliably make unhandled exceptions crash the event loop
On Mon, Feb 25, 2019 at 4:15 PM Josh Quigley <0zer...@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-considered-harmful/ 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 ___ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
