Proposal: Bind Promise Catch to Try/Catch scope

Kris Siegel krissiegel at gmail.com
Wed Jun 22 01:57:57 UTC 2016


So I understand the proposal what exactly is `window.callback.getCatch()`?

Is window the reference to the global object created in a browser context?
Since this group is for ECMAScript discussions referencing window, I think,
would be out of the question in this scope (perhaps more appropriate as a
WHATWG recommendation).

Or is window simply holding the callback yourself using (so essentially
removing the reference to `window` would keep your proposal the same)? If
so functions in ECMAScript can hold properties and other functions so this
could create a collision.

If the ultimate goal of this proposal is to allow the try catch pattern to
work across asynchronously executed code then I think await is really your
answer here. I think anything else may be a bit too complex though I'm
certainly open to hearing any ideas (not that my opinion technically
matters in that regard 🙂).

On Tue, Jun 21, 2016 at 6:49 PM, Todd Hubers <todd.hubers at alivate.com.au>
wrote:

> 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
> this front.
>
>
>
> Sent with MailTrack
> <https://mailtrack.io/install?source=signature&lang=en&referral=todd.hubers@alivate.com.au&idSignature=22>
>
> Regards,
>
> Todd Hubers (BBIT Hons)
> Software Engineer
>
> Contact <http://alivate.com.au/todd/> | Availability
> <https://www.google.com/calendar/embed?src=todd.hubers@alivate.com.au&ctz=Australia/Sydney>
>
> 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>
>> wrote:
>> > 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?
>>
>> ~TJ
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160621/fab497fc/attachment.html>


More information about the es-discuss mailing list