async_wrap: provide a way to act as an asynchronous try-catch

[acarstoiu]

@trevnorris, in just a few words, the async_wrap module should be capable of acting like a try{} catch() {} over asynchronous fragments, including nextTick (I'm aware of #6082) and timers. Why? To pave the way to replacing the current error domains.

In my view, the execution should simply not get to process._fatalException when the error is handled. I noticed that the API presented in this talk doesn't even pass the thrown value.

[trevnorris]

I originally implemented this behavior in AsyncListener almost 3 years ago (ref bc39bdd and 828f145). It leads to a hairy mess, and while I'm not opposed to it, it definitely won't be going into the initial public API. As a work around it is possible to setup and tear down an 'uncaughtException' handler in the pre/post callbacks. That should allow you to catch anything.

So, in short, let's wait until after initial implementation before discussing how to implement this.

[acarstoiu]

While I can live with using an uncaughtException listener (which can be interferred with by the running code), do you plan to have complete support for all asynchronous calls, including nextTick and timers in this initial release?

[trevnorris]

Yes. Initial release will have full support for timers, nextTick and a few other things that currently aren't properly supported.

[acarstoiu]

Great 👍

[acarstoiu]

Any progress on this? I really hope not to run on quick sands forever (namely, relying on the current error domains).

[trevnorris]

Yes. I'm furiously finishing it up in preparation for a PR.

[acarstoiu]

Any news on this?

[addaleax]

@acarstoiu You can track the progress of this at #11883, subscribe to that thread and you’ll know when this gets merged. :) I’m closing this, but feel free to let us know if it should be re-opened, or ask any follow-up questions that you have.