How to Replace Nested try…catch in JavaScript with Go‑Style Error Handling

async/await

is syntax sugar introduced in ES7 that fundamentally changes asynchronous programming in JavaScript, allowing code to be written in a seemingly synchronous style and greatly improving readability and maintainability.

However, the convenience of async/await brings along an "old friend": try...catch.

Root cause: try...catch

To catch the reject state of a Promise after an await, we must wrap the code in a try...catch block. For example, fetching user information from a server:

import { fetchUserById } from './api';
async function displayUser(userId) {
  try {
    const user = await fetchUserById(userId);
    console.log('用户信息:', user.name);
    // ... more operations based on user
  } catch (error) {
    console.error('获取用户失败:', error);
    // ... error handling logic, e.g., show a notification
  }
}

This code works, but when business logic becomes more complex—such as making multiple sequential requests—the code quickly turns into deeply nested try...catch structures:

async function loadPageData(userId) {
  try {
    const user = await fetchUserById(userId);
    console.log('用户信息:', user.name);
    try {
      const posts = await fetchPostsByUserId(user.id);
      console.log('用户文章:', posts);
      try {
        const comments = await fetchCommentsForPosts(posts[0].id);
        console.log('文章评论:', comments);
      } catch (commentError) {
        console.error('获取评论失败:', commentError);
      }
    } catch (postError) {
      console.error('获取文章失败:', postError);
    }
  } catch (userError) {
    console.error('获取用户失败:', userError);
  }
}

Seeing these layers of try...catch, do you feel a sense of suffocation? This approach has several obvious problems:

Code redundancy : each asynchronous operation repeats the try...catch structure, adding a lot of boilerplate.

Poor readability : the happy‑path code is wrapped in try blocks, increasing indentation and disrupting the natural reading flow.

Mixed concerns : success logic and failure logic are tightly coupled in the same block, reducing function responsibility.

Is there a way out of this dilemma? The answer is yes.

Elegant solution: Go‑style error handling

We can borrow Go's error‑handling pattern. In Go, functions typically return two values: result and error. Callers check whether error is nil to determine success.

We can bring this idea into JavaScript's async/await by creating a helper function (called to) that takes a Promise and never rejects. Instead, it always resolves to an array [error, data]:

If the Promise resolves, it returns [null, data].

If the Promise rejects, it returns [error, null].

Let's implement the to helper.

If you are not using TypeScript, the pure JavaScript version looks like this:

The to function is tiny but powerful. It encapsulates the try...catch logic internally and exposes a unified, flat interface.

Practical application: refactor our code

Now let's use the new to function to refactor the previous displayUser function:

Notice the transformation:

No try...catch anymore! The function body becomes very flat.

Error‑first handling : we first use an if guard clause to check and handle errors, returning early.

Highly readable : after error handling, the remaining code is the core happy‑path logic, clear and un‑nested.

New pattern advantages summary

Code is flatter and clearer : eliminates nested try...catch, keeping core logic at the top level.

Reduces boilerplate : error‑handling logic is encapsulated in the reusable to function.

Enforces error handling : destructuring const [error, data] forces developers to acknowledge error and not overlook it.

Separation of concerns : guard clauses separate error handling from success logic, making maintenance easier.

Combine with Promise.all

This pattern also shines when handling multiple concurrent requests.

async function loadDashboard(userId) {
  const [
    [userError, userData],
    [settingsError, settingsData]
  ] = await Promise.all([
    to(fetchUser(userId)),
    to(fetchUserSettings(userId))
  ]);

  if (userError) {
    console.error('加载用户数据失败');
    // handle user error
  }

  if (settingsError) {
    console.error('加载用户设置失败');
    // handle settings error
  }

  // Even if one fails, the other successful data remains usable
  if (userData) {
    // ...
  }
  if (settingsData) {
    // ...
  }
}

Using Promise.all together with to, you can elegantly handle scenarios where some promises succeed and others fail, whereas traditional try...catch would abort on the first rejection and discard all results. try...catch remains the cornerstone of JavaScript error handling; we are not trying to eliminate it entirely. Instead, we abstract and encapsulate it inside the to helper, keeping business code clean and focused.