Right now, MultiError.catch and MultiError.filter require that the callback they receive is synchronous. But it might happen at some point that someone wants to await inside a callback, just like you can inside an except: block or an __aenter__ method.
There are two reasons for this limitation: (1) the necessary chaining through to make the catch and filter code polymorphic with respect to async was pretty ugly, (2) bpo-29600 meant that async callbacks would always corrupt any exception they touched, which kinda ruined the whole thing.
However, bpo-29600 is fixed in mainline and the fix was backported to 3.6 and to 3.5. I believe the fix is in 3.6.1 (already released), and will also be in 3.5.4 (if and when that's released). And of course PyPy never had a problem with this.
So, it might be worth adding this feature back, though doing it in a maintainable way will still be tricky.
This isn't very urgent; I'm pretty sure no-one has yet run into a case where they actually need an async exception callback.
Right now,
MultiError.catchandMultiError.filterrequire that the callback they receive is synchronous. But it might happen at some point that someone wants toawaitinside a callback, just like you can inside anexcept:block or an__aenter__method.There are two reasons for this limitation: (1) the necessary chaining through to make the
catchandfiltercode polymorphic with respect to async was pretty ugly, (2) bpo-29600 meant that async callbacks would always corrupt any exception they touched, which kinda ruined the whole thing.However, bpo-29600 is fixed in mainline and the fix was backported to 3.6 and to 3.5. I believe the fix is in 3.6.1 (already released), and will also be in 3.5.4 (if and when that's released). And of course PyPy never had a problem with this.
So, it might be worth adding this feature back, though doing it in a maintainable way will still be tricky.
This isn't very urgent; I'm pretty sure no-one has yet run into a case where they actually need an async exception callback.