feat(rule): add wrap-await-with-try-catch rule

[can-keklik]

What is the purpose of this pull request?

• Documentation update
• Bug fix
• New rule
• Changes an existing rule
• Add autofixing to a rule
• Other, please explain:

What changes did you make? (Give an overview)

I've created a new rule named wrap-await-with-try-catch, which warns you if you don’t have try/catch around your awaits. For instance,

This would cause a warning:

await doSomething()

And this one is corrected:

try {
    await doSomething();
}
catch (ex) {
    //...
}

The rule basically traverses ancestors of the await expression to find a try block that has a catch clause. It was slightly trickier to implement the idea, though. If we simply looked for a TryStatement parent, the await, which is wrapped by a catch or a finally block, could be recognized as valid since catch and finally are children of try. For instance,

In the following await still has a TryStatement as an ancestor, but it is invalid for our case:

try {
    ...
}
catch (ex) {
    await doSomething();
}

And one of the possible fixes is below. The inner try/catch is ignored, we accept the outer one:

try {
    try {
        ...
    }
    catch (ex) {
        await doSomething();
    }
}
catch (ex) {
}

That is, the await expression must be in a try block, no matter how much nested it is. I don't offer a fixer, since the possible scenarios can be too complex to fix automatically.

[xjamundx]

Thanks for submitting this. I think I'm pretty happy merging this in.

Any thoughts on things like?

await doSomething().catch(handleError)

Which, honestly is my preference a lot of the time.

Should that also throw an error? IF this is more about style then definitely yes. If it's about correctness and safety I think it's a maybe.

[can-keklik]

Hello,

Thanks :)

Well, to be honest, I considered this as more of a warning about style. Using try/catch prevents most of the confusions about handling Promise errors imo. I admit that it introduces some verbosity, but still useful in terms of forcing a single style.

So yes, I think it should throw an error for that case too. Nonetheless, I am open to suggestions. We can think about adding an exception for .catch(handler) if that is common or requested by majority.