应捕获具体异常类型而非Exception，避免空catch和printStackTrace，用日志框架记录完整堆栈，finally中关闭资源需嵌套处理，禁用异常作控制流。
捕获 Exception 而不是具体异常类型
很多新手一上来就写 catch (Exception e)，以为“兜底”最安全。实际上这会掩盖本该由调用方处理的受检异常（如 IOException），也容易吞掉本该崩溃暴露的编程错误（比如 NullPointerException）。更糟的是，它让后续维护者无法区分哪些是预期业务异常、哪些是系统故障。
- 优先捕获明确的子类，例如
catch (FileNotFoundException e)或catch (IllegalArgumentException e) - 如果真要兜底，放在最后且必须记录日志：
catch (Exception e) { logger.error("未预期异常", e); throw new RuntimeException(e); } - 永远不要只写
catch (Exception e) { }—— 空 catch 是调试噩梦的起点
printStackTrace() 直接输出到控制台
开发时随手加 e.printStackTrace() 很方便，但上线后等于放弃异常可观测性：日志分散、无上下文、无法检索、不进集中日志系统。
- 一律改用日志框架（如 SLF4J）记录：
logger.warn("读取配置失败", e) - 确保异常对象作为第二个参数传入，否则堆栈信息丢失
- 避免拼接字符串记录异常消息（
e.getMessage()），它可能为null或不含关键路径信息
在 finally 块里做可能抛异常的操作
比如在 finally 里调用 close() 又没再 try-catch，一旦抛出新异常，会覆盖原始异常（即“异常屏蔽”），导致真正出问题的地方被隐藏。
- JDK 7+ 优先用 try-with-resources：
try (FileInputStream fis = new FileInputStream("a.txt")) { // 使用 fis } // 自动 close，且抑制 secondary exception - 如果手动关闭，务必嵌套处理：
finally { if (resource != null) { try { resource.close(); } catch (IOException ignored) { /* 记录但不抛 */ } } } - 不要在
finally里return或抛异常——它会劫持主流程返回值或异常
把异常当控制流用
例如用 NumberFormatException 来判断字符串是否为数字，或靠 ParseException 区分日期格式。这不仅性能差（异常构造开销大），还违背异常设计本意：异常用于“异常情况”，不是分支逻辑开关。
立即学习“Java免费学习笔记（深入）”；
- 数值校验用
StringUtils.isNumeric()（Apache Commons）或正则预判 - 日期解析前先用
DateTimeFormatter.parseBest()或自定义验证逻辑 - 基准测试显示，抛一次异常的耗时通常是普通条件判断的 100 倍以上
真实项目里最棘手的往往不是语法错误，而是异常被静默吞掉、堆栈被截断、或者原始错误被二次异常覆盖——这些不会报编译错误，却让问题排查时间翻倍。
