随机 try-catch（有的地方 'try-catch'，有的地方直接崩）

随机 try-catch 是一种常见的代码风格，尤其在快速迭代的项目中容易出现。有些开发者习惯性地在关键路径包裹 try-catch，而忽略非核心逻辑的错误处理，导致程序出现局部崩溃与全局捕获并存的矛盾现象。

典型场景分析

在异步操作密集的前端代码里，这种模式尤为明显。比如一个电商网站的购物车模块可能这样处理价格计算：

async function calculateTotal() {
  try {
    const items = await fetchCartItems(); // 包裹try-catch
    let total = 0;
    items.forEach(item => {
      // 这里故意不处理可能的数值转换错误
      total += parseFloat(item.price) * item.quantity;
    });
    return applyDiscounts(total); // 另一个可能抛出异常但未捕获的点
  } catch (e) {
    console.error('获取购物车商品失败', e);
  }
}

反模式的具体表现

1. 选择性捕获：只拦截已知风险点，忽略潜在问题
2. 错误吞噬：catch块内仅打印日志不做恢复处理
3. 层级混乱：在三级嵌套函数突然加入try-catch

表单验证场景的典型例子：

function validateForm() {
  // 外层不捕获
  const email = document.getElementById('email').value;
  if (!email.includes('@')) throw new Error('Invalid email');

  try {
    // 内层突然捕获
    const age = parseInt(document.getElementById('age').value);
    if (age < 18) throw new Error('Underage');
  } catch (e) {
    alert(e.message);
  }
}

框架中的特殊表现

React组件内这种模式可能更隐蔽：

function UserProfile() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetchUserData().then(data => {
      // 不处理可能的undefined访问
      setData({
        name: data.user.name,
        // 下一行可能直接崩溃
        lastLogin: new Date(data.meta.last_access).toLocaleString()
      });
    }).catch(e => {
      console.log('获取用户数据失败'); // 仅处理了fetch错误
    });
  }, []);

  return <div>{data?.profile.bio}</div>; // 可选链掩盖了问题
}

技术债务的积累过程

这种模式往往随着需求变更逐步形成：

1. 首次实现时只处理主要异常
2. 后续新增功能直接延续原有模式
3. 临界条件测试不足导致遗漏
4. 最终形成"补丁式"错误处理

典型的时间处理函数演变：

// v1.0 基础功能
function formatDate(dateStr) {
  return new Date(dateStr).toISOString().split('T')[0];
}

// v2.0 增加容错
function formatDate(dateStr) {
  try {
    return new Date(dateStr).toISOString().split('T')[0];
  } catch {
    return 'invalid date';
  }
}

// v3.0 特殊逻辑
function formatDate(dateStr) {
  if (dateStr === 'now') return new Date().toISOString();
  
  // 忘记处理null/undefined情况
  const parts = dateStr.split('-');
  if (parts.length === 3) {
    return `${parts[2]}/${parts[1]}/${parts[0]}`;
  }
  
  // 原始try-catch仍然存在但覆盖不全
  try {
    return new Date(dateStr).toISOString().split('T')[0];
  } catch {
    return 'invalid date';
  }
}

性能与调试影响

不规范的错误处理会导致：

• 错误边界模糊，难以定位原始抛出点
• 控制台警告与未捕获异常混杂
• 错误恢复策略不一致

// 性能监控可能漏报
metrics.startRecording('checkout');
try {
  await processPayment(); // 被捕获的异常
  await updateInventory(); // 未捕获的异常
} catch (e) {
  metrics.logError('payment_failed'); // 只记录支付错误
}
metrics.endRecording('checkout'); // 库存异常时不会执行

现代浏览器的异常追踪

DevTools 对这类问题的显示差异：

function main() {
  riskyOperationA(); // 控制台显示未捕获错误
  try {
    riskyOperationB(); // 控制台不显示
  } catch {}
  riskyOperationC(); // 再次显示未捕获错误
}

Chrome调试器会标记：

• 未捕获异常带红色错误图标
• 已捕获异常仅在抛出点显示灰色提示

团队协作中的扩散

这种模式容易通过代码评审传播：

1. 新人模仿现有代码风格
2. 紧急修复采用相同模式
3. 逐渐成为项目"特色"

代码评审注释示例：

"这里是不是应该像XX模块那样加个try-catch？" "之前类似功能就是这么写的"

类型系统的假象安全

TypeScript项目中尤为危险：

interface Product {
  price: string;
  discount?: {
    amount: number;
  };
}

function getFinalPrice(product: Product) {
  try {
    const base = parseFloat(product.price);
    // TS不报错但运行时可能崩溃
    return base - product.discount.amount;
  } catch {
    return base; // 可能未定义
  }
}

测试覆盖率陷阱

这种模式会导致测试通过率虚高：

// 测试用例
it('should handle invalid input', () => {
  expect(processInput('valid')).toBe(true);
  expect(() => processInput(null)).not.toThrow(); // 通过
});

// 实际实现
function processInput(input) {
  try {
    return input.trim().length > 0;
  } catch {
    return false; // 看似处理了null，但undefined呢？
  }
}

错误边界的误用

React Error Boundary的典型滥用：

// 父组件
<ErrorBoundary>
  <UserProfile />  // 内部已有try-catch
  <ShoppingCart /> // 完全没有错误处理
</ErrorBoundary>

// UserProfile组件内部
async function loadData() {
  try {
    const res = await fetch('/api/profile');
    return await res.json(); // 可能抛出SyntaxError
  } catch {
    return { fallback: true }; // 吞掉错误
  }
}

构建工具的掩盖

Webpack等工具可能隐藏源码问题：

原始代码：

function getConfig() {
  // 忘记处理import错误
  return require(`./configs/${env}.json`);
}

编译后变成：

function getConfig() {
  try {
    return __webpack_require__(`./configs/${env}.json`);
  } catch {
    return {}; // 自动添加的容错处理
  }
}

第三方库的传染效应

流行库的处理方式会影响项目风格：

// 模仿axios的响应结构
try {
  const res = await someAPI();
  if (res.error) {
    throw new Error(res.error.message); // 需要捕获
  }
  return res.data.someField; // 可能undefined
} catch (err) {
  // 只处理了显式throw
  showToast(err.message);
}

事件循环中的隐藏问题

异步代码的异常处理更易遗漏：

document.addEventListener('click', async (e) => {
  // 未处理的Promise rejection
  if (e.target.matches('.async-btn')) {
    const data = await fetchData();
    updateUI(data.items[0]); // 可能越界
  }
});

// 另一个事件处理器
document.querySelector('.sync-btn').onclick = () => {
  try {
    syncOperation();
  } catch {
    // 只有同步错误被捕获
  }
};

样式计算中的静默失败

CSS相关操作也常见此模式：

function setTheme(theme) {
  // 不检查元素是否存在
  document.documentElement.style.setProperty('--primary', theme.color);
  
  try {
    // 过度保护
    const btn = document.querySelector('.btn');
    btn.style.backgroundColor = theme.btnColor;
  } catch {
    console.log('按钮不存在');
  }
}