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.