Proposal: Bind Promise Catch to Try/Catch scope
todd.hubers at alivate.com.au
Wed Jun 22 01:49:36 UTC 2016
Good questions Tab
1. Mixtures of async/await and callback code. As much as you want purity it
doesn't always happen.
2. Related to the previous question. Those who have mixtures of async/await
and callback code.
I've used await a lot in C#/.NET, it isn't the cure of the diagnosed
callback disease, but it is a great treatment. In some coding scenarios I
have found the await keyword to be more cumbersome than callbacks. This
could be due to the way C# implements it - all functions which await must
return a Task object, and if the method is decorated with async, it must
await. In .Net it's multithreaded and not an event loop by default, so it
can be more complicated. I was building a TCP server recently with C# and
gave up, ripped out all the async/await and replaced with callbacks. It was
so much easier.
I don't have academic references handy which would back up my claim that
"await doesn't solve all async problems, and can actually work against you
in some scenarios in ES". Perhaps there are others who can support me on
Sent with MailTrack
Todd Hubers (BBIT Hons)
Contact <http://alivate.com.au/todd/> | Availability
On 22 June 2016 at 11:37, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Tue, Jun 21, 2016 at 6:15 PM, Todd Hubers <todd.hubers at alivate.com.au>
> > 1. Whether you await or not, the try scope's catch callback [TSCC]
> should still be captured.
> Why? Async code doesn't do anything special for try/catch anywhere
> else in the language - what does this proposal do that's worth the
> added complexity beyond what just using a Promise and the await/async
> keywords can do?
> > 2. If there is no use of Promise (for coders own design reasons) the try
> scope's catch callback [TSCC] should be available
> What uses are you thinking of, and why should this be available?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss