JS异步函数Promise规范确认及同步函数成败标识方式咨询

Great question! Let's break this down step by step to clarify both your async function best practice check and your sync function question.

一、你的异步函数规范认知完全正确！ #

First off, you’ve got this exactly right. Promises (and async/await, which is syntactic sugar for Promises) are designed around two clear states:

• resolve signals that an operation completed successfully and should carry the result of that operation.
• reject signals that an operation failed and should carry an Error object with context about why it failed.

This pattern is so powerful because:

• It lets you use try/catch (or .catch() for raw Promises) to centralize error handling, avoiding messy nested conditionals.
• The Error passed to reject includes stack traces and custom messages, making debugging way easier than just getting a false value.
• It aligns with universal JavaScript async programming conventions, so other developers will immediately understand your code.

良好实践（Good） #

const doSomething = async () => {
  // 模拟业务逻辑
  if (someFailureCondition) {
    reject(new Error("Failed to complete: network timeout"));
  }
  resolve("Success! Here's your data");
};

// 调用示例
try {
  const result = await doSomething();
  console.log(result);
} catch (error) {
  console.error("Handling failure:", error.message);
}

This keeps success and failure logic clearly separated, and puts all error handling in one place.

不推荐的实践（Bad） #

const doSomething = async () => {
  // 模拟业务逻辑
  if (someFailureCondition) {
    resolve(false);
  }
  resolve(true);
};

// 调用示例
const didWork = await doSomething();
if (didWork) {
  console.log("It worked");
} else {
  // 完全不知道失败原因
  console.log("It failed... but why?");
}

This approach has critical flaws:

• You lose all context about why the operation failed, making debugging a nightmare.
• Callers have to remember to check the boolean return value—miss this step, and you’ll get silent failures.
• It misuses resolve, which is meant to pass successful results, not status flags.

二、同步函数返回true/false是否为不良习惯？分场景看！ #

Returning true/false isn’t inherently bad—it depends entirely on what your function does. Let’s break down the cases:

1. Perfectly fine to return booleans #

If your function is a pure conditional check (verifying a state or rule), booleans are the clearest, most concise choice. For example:

function isPasswordStrong(password) {
  return password.length >= 8 && /[A-Z]/.test(password);
}

if (isPasswordStrong(userInput)) {
  console.log("Strong password!");
}

Here, the boolean directly answers the question "is this password strong?"—no ambiguity, no extra context needed.

2. Better alternatives when returning booleans falls short #

If your function performs an action (like processing data, reading a file, or validating input) where failure needs context, true/false won’t cut it. Here are better options:

方式一：Throw errors (for unexpected failures)

If the failure is an exception (e.g., a file doesn’t exist, invalid parameters), throw an Error and let callers handle it with try/catch. This matches async error handling patterns, keeping your code style consistent:

function parseJsonString(json) {
  try {
    return JSON.parse(json);
  } catch (e) {
    throw new Error(`Invalid JSON: ${e.message}`);
  }
}

try {
  const data = parseJsonString(userInput);
  console.log("Parsed data:", data);
} catch (error) {
  console.error("Parsing failed:", error.message);
}

方式二：Return a status object (for expected failures)

If failures are predictable (e.g., form validation errors), return an object that includes a success flag, result data (if successful), and error context (if failed):

function validateUserForm(formData) {
  if (!formData.email) {
    return {
      success: false,
      error: new Error("Email is required")
    };
  }
  if (!formData.password) {
    return {
      success: false,
      error: new Error("Password is required")
    };
  }
  return {
    success: true,
    data: formData
  };
}

const validationResult = validateUserForm(submittedData);
if (validationResult.success) {
  submitForm(validationResult.data);
} else {
  showError(validationResult.error.message);
}

This gives callers full control over handling both success and failure cases, with clear context.

方式三：Return result/null (for simple cases)

For straightforward actions where failure just means "no result found", return the result on success and null on failure. Just be careful with falsy values (like 0 or empty strings) that might be mistaken for failure:

function findUserById(users, id) {
  const match = users.find(user => user.id === id);
  return match ?? null;
}

const user = findUserById(usersList, 123);
if (user) {
  console.log("Found user:", user);
} else {
  console.log("User not found");
}

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