# Managing unhandled exceptions from asyncio

**URL:** <https://discuss.python.org/t/managing-unhandled-exceptions-from-asyncio/73136>\
**Category:** Async-SIG\
**Created:** [December 3, 2024, 7:05am UTC](https://discuss.python.org/t/managing-unhandled-exceptions-from-asyncio/73136 "2024-12-03T07:05:07Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![achimnol](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/achimnol/32/28061_2.png) [@achimnol](https://discuss.python.org/u/achimnol)\
**Post date:** [December 22, 2024, 7:17am UTC](https://discuss.python.org/t/managing-unhandled-exceptions-from-asyncio/73136/7 "2024-12-22T07:17:17Z")

</div>

In my previous article ([Server-oriented task scope design - #2 by achimnol](https://discuss.python.org/t/server-oriented-task-scope-design/53903/2)), I’ve suggested to have a nested tree of “task scope” (or “supervisor scope”) for an asyncio server application. One of the core idea is to be able to consume the unhandled exceptions in a hierarchical manner, instead of relying on the global `loop.set_exception_handler()`.

Without impacting existing asyncio applications, I think we could reconsider the concept of nested task scopes.

---

_[View the full topic](https://discuss.python.org/t/managing-unhandled-exceptions-from-asyncio/73136)._