Proposal: Bind Promise Catch to Try/Catch scope

Todd Hubers todd.hubers at alivate.com.au
Wed Jun 22 02:08:48 UTC 2016


Hi Kris,

[3]. RE: window.callback.getCatch

"So I understand the proposal what exactly is `window.callback.getCatch()`?"
My initial (poor) attempt at illustrating an API for accessing the try
scope catch callback [TSCC]. The ES implementation would track this, not
the browser. Very happy for any suggestions there.

"Is window the reference to the global object created in a browser
context?..."
Well it's a stack of try scope catch callback [TSCC]s. Because try blocks
can be nested. But that's an underlying implementation detail. The API
should simply have something like `getTryScopeCatchCallback()`

[1],[2]. RE: Debate on whether a Promise with await is enough
"then I think await is really your answer here"
If you believe that async/await is the ultimate solution that works in all
situations then that's fine. But I disagree. And therefore if a Promise has
the benefit of reaching the TSCC, it should be open for non-await patter
access too.

I appreciate the rigorous debate.

BTW, I wonder if some sort of polyfill would work:

getTryScopeCatchCallback()
{
    return new Promise().throw; // This is a complete guess, and unlikely
right. Is there a hacky way to get the TSCC already?
}


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:57, Kris Siegel <krissiegel at gmail.com> wrote:

> 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/20160622/c0a91a7a/attachment-0001.html>


More information about the es-discuss mailing list