Proposal: Bind Promise Catch to Try/Catch scope

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: Bind Promise Catch to Try/Catch scope

Todd Hubers
see http://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.

Regards,

Todd Hubers (BBIT Hons)
Software Engineer




Sent with MailTrack

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Bind Promise Catch to Try/Catch scope

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

e. g.:
```js
try {
  await curl("example.com");
  /* success */
}
catch (e) {
  /* error */
}
```

On Mittwoch, 22. Juni 2016 10:55:24 CEST Todd Hubers wrote:

> see http://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.
>
> Regards,
>
> Todd Hubers (BBIT Hons)
> Software Engineer
>
> Contact <http://alivate.com.au/todd/> | Availability
> <https://www.google.com/calendar/embed?src=todd.hubers@...&ctz=Australia/Sydney>
>
>
>
> Sent with MailTrack
> <https://mailtrack.io/install?source=signature&lang=en&referral=todd.hubers@...&idSignature=22>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Bind Promise Catch to Try/Catch scope

Todd Hubers
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

On 22 June 2016 at 11:06, kdex <[hidden email]> wrote:
Why not just transform callback-based APIs into `Promise`s and use (presumably ES2017)
`await`/`async` (which *does* support `try`/`catch`)?

e. g.:
```js
try {
  await curl("example.com");
  /* success */
}
catch (e) {
  /* error */
}
```

On Mittwoch, 22. Juni 2016 10:55:24 CEST Todd Hubers wrote:
> see http://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.
>
> Regards,
>
> Todd Hubers (BBIT Hons)
> Software Engineer
>
> Contact <http://alivate.com.au/todd/> | Availability
> <https://www.google.com/calendar/embed?src=todd.hubers@...&ctz=Australia/Sydney>
>
>
>
> Sent with MailTrack
> <https://mailtrack.io/install?source=signature&lang=en&referral=todd.hubers@...&idSignature=22>
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Bind Promise Catch to Try/Catch scope

Tab Atkins Jr.
On Tue, Jun 21, 2016 at 6:15 PM, Todd Hubers <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Bind Promise Catch to Try/Catch scope

Todd Hubers
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

Regards,

Todd Hubers (BBIT Hons)
Software Engineer


On 22 June 2016 at 11:37, Tab Atkins Jr. <[hidden email]> wrote:
On Tue, Jun 21, 2016 at 6:15 PM, Todd Hubers <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Bind Promise Catch to Try/Catch scope

Kris Siegel
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 <[hidden email]> 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

Regards,

Todd Hubers (BBIT Hons)
Software Engineer


On 22 June 2016 at 11:37, Tab Atkins Jr. <[hidden email]> wrote:
On Tue, Jun 21, 2016 at 6:15 PM, Todd Hubers <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Bind Promise Catch to Try/Catch scope

Todd Hubers
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

Regards,

Todd Hubers (BBIT Hons)
Software Engineer


On 22 June 2016 at 11:57, Kris Siegel <[hidden email]> 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 <[hidden email]> 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
<img width="0" height="0" src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7">

Regards,

Todd Hubers (BBIT Hons)
Software Engineer


On 22 June 2016 at 11:37, Tab Atkins Jr. <[hidden email]> wrote:
On Tue, Jun 21, 2016 at 6:15 PM, Todd Hubers <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss