如何避免使用Promise catch控制程序流程？代码优化咨询

Great question—this is a common pitfall when working with Promises. Let's break this down clearly:

First: Is this approach a best practice? #

It depends entirely on what the rejected state represents.

• If the rejected state is for unexpected errors (e.g., network failures, permission issues, corrupted files), using catch to handle those errors (operation B) is valid and part of proper error handling.
• However, if the rejected state is for expected business logic branches (e.g., "file doesn't exist" is a normal, anticipated scenario in your app), using catch for this flow control is not a best practice. Here's why:
  • It blurs the line between "errors" and "normal business outcomes", making your code harder to read and maintain for other developers (or future you).
  • The catch block will also catch any errors thrown inside operation A, which can lead to unintended behavior and tricky debugging.

How to rewrite the code to avoid anti-patterns #

Case 1: Operation B is an expected business branch #

If "getFile 'failing'" is a normal part of your logic (like checking for an optional config file), adjust getFile to return a resolved Promise with a status indicator instead of rejecting. Then handle both paths in a single then block:

Rewritten Promise code:

// First, adjust getFile to return a status object instead of rejecting
function getFile() {
  return new Promise(resolve => {
    // Replace with your actual file check logic
    const fileExists = checkIfFileExists();
    
    if (fileExists) {
      resolve({ success: true, data: "File content here" });
    } else {
      resolve({ success: false, reason: "File not found" });
    }
  });
}

// Now handle both paths clearly in one then block
getFile()
  .then(result => {
    if (result.success) {
      // Operation A: File exists, proceed with your logic
      console.log("Processing file:", result.data);
    } else {
      // Operation B: File doesn't exist, run fallback logic
      console.log("File missing, using default settings");
    }
  })
  // Only catch *actual* unexpected errors here (e.g., IO failures)
  .catch(error => {
    console.error("Unexpected error during file operation:", error);
  });

Async/Await version (more readable for most cases):

async function handleFile() {
  try {
    const result = await getFile();
    
    if (result.success) {
      // Operation A
      console.log("Processing file:", result.data);
    } else {
      // Operation B
      console.log("File missing, using default settings");
    }
  } catch (error) {
    // Handle true exceptions only
    console.error("Unexpected error:", error);
  }
}

handleFile();

Case 2: Operation B is error handling for unexpected failures #

If the rejected state is truly an error (e.g., network error when fetching a remote file), your original approach is acceptable, but using async/await with try/catch will make the code more linear and readable:

async function handleFile() {
  try {
    await getFile();
    // Operation A: Success case logic
    console.log("File loaded successfully");
  } catch (error) {
    // Operation B: Handle unexpected error
    console.error("Failed to load file:", error);
    // Add fallback logic here if needed
  }
}

handleFile();

Key Takeaway #

Use Promise.reject and catch only for unexpected errors, not for normal business flow branches. For expected alternative paths, resolve the Promise with a status object and use conditional logic to handle each case. This keeps your code intent clear and avoids accidental error swallowing.

内容的提问来源于stack exchange，提问作者BAE