Photo by Headway on Unsplash

Recently I have seen some developers use this approach to handle async/await errors:

As you can see, they wrap the function to convert the original Promise into a “Promise” that will definitely succeed and return an array.

If the original Promise succeeded, then the first item in the array is null indicating no error, and the second is the result of the original Promise. If the original Promise fails, the first item of the array is an error and the second item is undefined. That’s it.

They think it’s elegant and makes the code more readable. But I don’t think so, and I don’t recommend you use it that way!

I think such encapsulation is a bit over-engineered, and in most cases, you don’t need to. Next, I will illustrate my point of view from two perspectives:

1. From a design perspective

The purpose of the async/await API is to allow developers to write asynchronous code like synchronous code. So async/await errors can be caught using try...catch.

And such a function seems to have everything in mind for us, but other developers who have just seen your code will always have this question: Why is the await used by the Promise returned by the to function not wrapped in try...catch?

Only by finding the original to function definition, and understanding its intent, can you know "Ah, it turns out that the Promise returned by the to function will never be rejected".

So it further increases the cost of understanding for other developers, making the familiar async/await less "familiar".

2. From a practicality standpoint

The main use case of the to function is when there are multiple await promises in the same context, and their corresponding error handling is different. Then use this wrapper function to handle each error differently, reducing the use of try...catch.

But in actual writing, after each to function, you need to use the if statement to determine whether there is an error. This is no different in intent than using try...catch, it’s all about checking for errors.

Second, in a real production environment, it’s not uncommon for the next Promise to depend on the previous Promise. But the important point is that these two promises are usually associated functions. So using a try...catch in the outer layer to handle errors uniformly is no problem. For example:

Finally, in JavaScript, most Promise scenarios are on Input/output, such as network IO and file IO. These IO scenarios can encapsulate interceptors in the lower layer and process them uniformly according to the error code. For example, using axios interceptor:

So it may not be as practical as expected. That is, it may only be used on a small part of the overall project, and the costs outweigh the benefits.

That’s all my point, what do you think? Do you approve of this approach?