异步API调用中如何抛出自定义错误？以S3删除对象场景为例

原代码存在两处逻辑偏差：

1. 绝大多数S3 SDK的headObject接口在对象不存在时会直接抛出NotFound异常，不会返回错误对象给err变量，原有的判断逻辑永远不会命中
2. 条件判断误用了位与运算符&，应该用逻辑与&&

推荐的优化实现模式 #

采用错误分层提前处理+统一兜底的模式，比原有「try内抛错再统一catch包装」的逻辑更清晰，也能支持更精细化的错误分类，示例代码如下：

try {
  await s3.deleteObject(bucketParams);
  
  // 强校验删除结果的逻辑（非必需，按需开启）
  try {
    await s3.headObject(bucketParams);
    // 走到这里说明headObject成功，对象仍然存在，删除失败
    return {
      code: 409, // 用业务错误码代替通用500，更符合语义
      message: `${key} 删除失败，对象仍存在`
    }
  } catch (headErr) {
    if (headErr.code === 'NotFound') {
      // 符合预期，对象已删除
      return { code: 200, message: `${key} 成功删除` }
    }
    // headObject抛出其他错误，往外抛到外层catch处理
    throw headErr
  }
} catch (error) {
  // 按错误类型返回不同的响应，不用全部包装成500
  let code = 500
  let message = '删除操作失败'
  switch(error.code) {
    case 'AccessDenied':
      code = 403
      message = '没有S3操作权限'
      break
    case 'InvalidKey':
      code = 400
      message = '非法的对象key'
      break
    case 'NetworkError':
      message = '网络异常，请稍后重试'
      break
    default:
      message = error.message || message
  }
  throw new Error(code, message)
}

优化点说明 #

• 避免无意义的异常流转：对象未删除的业务场景直接返回对应结果，不需要先抛自定义字符串再进入catch二次处理，逻辑链路更短，可读性更高
• 错误分类更清晰：针对S3返回的已知错误类型返回对应语义的状态码，方便调用方做差异化处理，比全部返回500的兼容性更好
• 保留统一兜底能力：外层catch仍然负责处理所有未提前处理的异常，不会遗漏错误场景
• 修复了原代码的headObject逻辑错误，符合S3 SDK的实际调用规则

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