直接在方法内用try-catch捕获异常是最轻量的局部处理方式，需精准匹配具体异常类型、善用异常对象信息、配合try-with-resources或finally保障资源安全，并严禁空catch。
直接在方法内部用 try-catch 块捕获异常，是最常用、最轻量的局部异常处理方式。它不依赖外部框架或额外配置，适用于单个方法内需要隔离错误、避免中断主流程、或对不同错误做差异化响应的场景。
明确异常类型，按需设置 catch 块
不要笼统地 catch Exception 或 Throwable。应根据业务逻辑中实际可能抛出的异常，精准匹配子类。例如读文件时优先捕获 FileNotFoundException 和 IOException；解析数字时捕获 NumberFormatException；除法运算关注 ArithmeticException。
- 多个异常类型需分开写多个 catch 块，Java/C# 会按顺序匹配第一个能处理的类型
- 若使用 Java 7+，可用 ArithmeticException | NullPointerException 语法合并处理逻辑相同的异常
- PHP 和 Python 中也支持多 except / catch，但注意 PHP 的异常继承链、Python 的 except 顺序同样影响匹配结果
在 catch 中访问并利用异常变量
catch 后声明的异常参数（如 e）不是占位符，而是真实异常对象，可调用其方法获取关键信息：
- e.getMessage()：获取简明错误描述，适合记录日志或返回用户提示
- e.getStackTrace() 或 e.printStackTrace()：用于调试，不建议在生产环境直接输出到前端
- e.getCause()：当异常是包装型（如 SQLException 包裹了 IOException），可逐层追溯根因
- 部分语言（如 C#）还支持 e.Source、e.HResult 等属性，辅助定位模块或系统级问题
配合 finally 或 try-with-resources 保障资源安全
如果 try 块中打开了流、连接或锁等资源，仅靠 catch 不足以防止泄漏。必须确保清理动作执行：
- Java 推荐用 try-with-resources 语句（自动调用 close()），比手动 finally 更简洁可靠
- 传统 finally 块中关闭资源时，自身也可能抛异常（如关闭文件流时报 IOException），此时应在 finally 内再套一层 try-catch，或使用工具类静默关闭
- C# 中 using 语句与 Java 的 try-with-resources 功能一致；PHP 则需显式在 finally 中 fclose() 或 unset()
避免空 catch 或吞掉异常
写成 catch (Exception e) { } 是危险习惯——表面“稳住”了程序，实则掩盖问题、阻碍排查。正确做法是至少记录日志：
- 简单场景：log.error("读取配置失败", e);
- 需要降级时：在 catch 中提供默认值或备用路径（如缓存数据、空列表），并注明“已降级”
- 绝不忽略异常后继续用未初始化/非法状态的对象，否则可能引发更隐蔽的 NullPointerException 或数据错乱
