When you have learned about JavaScript promises for the first time, you learned about the promiseâs methods then and catch. While the formerâs callback function is called whenever a JavaScript promise resolves successfully, the latter is used for error handling:
Eventually you have learned about async/await in JavaScript as alternative to a JavaScript promiseâs then and catch methods:
The shift from then/catch to async/await was a pretty powerful one, because suddenly you would be able to read your code in a synchronous way again. Every line happening after the await statement has to wait until the promise resolves. In addition, writing code like this felt way more concise. But then there is the error handling for async/await with a try/catch block:
This broke all the conciseness from async/await again, because instead of having asynchronous callbacks in then/catch blocks, we ended up with a try/catch block surrounding everything. So what if you could get the best out of both worlds?
This works, the only flaw here is that in a case of an error all the code after the await statement will still execute. We would have to guard it with a condition, but only if you would need to avoid this behavior:
We could also return the error and do the error handling in the if block:
Now you ended up without a bulky try/catch block but a guarding if clause in case an error (or nothing) is returned from your JavaScript promise. Whether this makes things cleaner than using a try/catch block is up to you. Maybe it is for certain scenarios, however, I have learned that going with the standard implementation of try/catch is preferred when working with other developers on one code base to establish a common sense.