ideas, await singular and multiple, block, try catch short hand, functioncall.catch(e) {} or .catch(e =>)

[wesleyolis]

Suggestion

I am going to just throw this out their for debate, I may be right or I may be wrong, just few ideas, take what you like from it, just putting it out their.
Basically await allows code to look sync and simpler to follow and also by default wired up the catch forward handling to the parent caller scope. This means we then use the very verbose try{await .. } catch(e){if(x), throw x} syntax. I would like to suggest a much simpler neater syntax.
were by .catch can be called on the end of function or await function. the catch function that is called
called must return if it handles the exception otherwise it will by default be re-throw.
This depending on how implemented, could possible allow for speed up as the catch error forwarding
can be handled in the promise execution environment as long as it doesn't reference anything outside its scope. The implementation details, of the wiring could allow for delay forwarding the exception up argumented call stack. If the compiler is intelligent is could keep track of whether the statement is being called within the a nested try catch block, if their is no nested try catch block, then it doesn't need to generate forwarding code and can just call a default registered promise catch handler that was register at a global scope with the Promise library from its current execution stack, potentially gaining a speed up as the code to augment the call stacks need not be generated.

Basically one looks at loosing the .then
were , is sequences and colon is parellel execution.

Use Cases

async function aAsync() {}
async function bAsync() {}
async function cAsync() {}
async function dAsyncSequence() {}

Case A, Promise chain run in sequence

async function run()
{
 await aAsync().catch(e => console.log(e));
 await aAsync(), bAsync(), cAsync().catch(e => console.log(e));
}

Case B, Promise chain run in parallel

async function run()
{
await aAsync(): bAsync(): cAsync(), dAsyncSequence,  catch(e => console.log(e));
// dAsyncSequence is run after aAsync, bAsync, cAsync

await aAsync():
bAsync():
cAsync(),
 dAsyncSequence,  catch(e => console.log(e));
}

Case B, Promise chain run in sequence

async function run()
{
await aAsync(), bAsync(), cAsync(), catch(e => console.log(e));
}

Case C

async function run()
{
 await {
     aAsync();
     bAsync();
     cAsync();
 }.catch(e => console.log(e));
}

Case D

async function run()
{
 try await {
     aAsync();
     bAsync();
     cAsync();
 }.catch(e => console.log(e));
}

Case E

async function run()
{
 try {
     await aAsync();
     await bAsync();
     await cAsync();
 }.catch(e => console.log(e));
}

Checklist

50/50 means its up to were you decided to cut the optermization with regards to Promise handling.

My suggestion meets these guidelines:

• [X ] This wouldn't be a breaking change in existing TypeScript / JavaScript code
• [X(50/50] This wouldn't change the runtime behavior of existing JavaScript code
• [ 50/50] This could be implemented without emitting different JS based on the types of the expressions
• [50/50 ] This isn't a runtime feature (e.g. new expression-level syntax)

[kitsonk]

This is absolutely new expression level syntax. Changes like this should be addressed in ECMAScript, not in TypeScript. The right forum to discuss something like this is advocating it with TC39 or on ESDiscuss.

[wesleyolis]

Thanx, I shall look in to doing that.

In light some recent developments, the following await, key word would be replaced with the positive keyword of async, with reference to exploring some other ideas in this requested feature.

#25448

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.