Discuss
  • Proposal: Bind Promise Catch to Try/Catch scope

Proposal: Bind Promise Catch to Try/Catch scope

# Todd Hubers (8 years ago)

see blog.alivate.com.au/callback-api-for-es6

Problem: Try blocks don’t work in a callback world.

Proposed solution:

  • Implement API: window.callback.getCatch() - which is a callback to the parent catch block scope.
    • Ie. While the try scope is entered, internally the catch handler is stored as a function (window.callback.activeCatch.push(thisCatch)). When the try scope is left, that value is popped.
  • Promise: defaults its catch callback to whatever getCatch() returns

I'm sure there are plenty more details that could be covered and "Callback API" and "getCatch" are totally open to debate. But I hope you get the gist of it efficiently with this email.

,

Todd Hubers (BBIT Hons) Software Engineer

Contact alivate.com.au/todd | Availability www.google.com/calendar/[email protected]&ctz=Australia/Sydney

Sent with MailTrack mailtrack.io/install?source=signature&lang=en&[email protected]&idSignature=22

# kdex (8 years ago)

Why not just transform callback-based APIs into Promises and use (presumably ES2017) await/async (which does support try/catch)?

e. g.:

try {
  await curl("example.com");
  /* success */
}
catch (e) {
  /* error */
}
# Todd Hubers (8 years ago)
  1. Whether you await or not, the try scope's catch callback [TSCC] should still be captured.
  2. If there is no use of Promise (for coders own design reasons) the try scope's catch callback [TSCC] should be available
# Tab Atkins Jr. (8 years ago)

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?

  1. 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?

# Todd Hubers (8 years ago)

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 mailtrack.io/install?source=signature&lang=en&[email protected]&idSignature=22

,

Todd Hubers (BBIT Hons) Software Engineer

Contact alivate.com.au/todd | Availability www.google.com/calendar/[email protected]&ctz=Australia/Sydney

# Kris Siegel (8 years ago)

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 🙂).

# Todd Hubers (8 years ago)

[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 mailtrack.io/install?source=signature&lang=en&[email protected]&idSignature=22

,

Todd Hubers (BBIT Hons) Software Engineer

Contact alivate.com.au/todd | Availability www.google.com/calendar/[email protected]&ctz=Australia/Sydney