必须用try-catch处理编译期异常（如IOException、SQLException），运行时异常（如NullPointerException）应修复逻辑而非捕获；资源操作优先用try-with-resources；catch中重抛需保留原始异常栈轨迹。
什么时候必须用 try-catch，什么时候可以不用
Java 中 try-catch 不是万能兜底工具，也不是所有异常都该捕获。编译期异常（Exception 及其子类，但不包括 RuntimeException）必须处理——要么 try-catch，要么在方法签名加 throws。运行时异常（如 NullPointerException、ArrayIndexOutOfBoundsException）可不捕获，因为它们通常反映逻辑错误，应靠修复代码而非掩盖异常来解决。
常见误用：对 Integer.parseInt(str) 硬套 try-catch 而不先校验 str 是否为空或纯数字。这会让异常成为控制流，性能差且难调试。
- 必须捕获：文件读写（
IOException）、网络请求（SQLException、UnknownHostException）等外部依赖失败场景 - 建议不捕获：
NullPointerException、IllegalArgumentException—— 应提前用Objects.requireNonNull()或空检查拦截 - 谨慎捕获：
Exception或Throwable—— 容易吞掉OutOfMemoryError这类致命错误
多个 catch 块的顺序与合并写法
多个 catch 块必须按「子类在前、父类在后」排列，否则编译报错：error: exception XXX has already been caught。Java 7 起支持多异常捕获语法，用 | 分隔，但要注意：被合并的异常类型不能有继承关系，且共用一个处理逻辑时才适用。
try {
doSomething();
} catch (IOException | SQLException ex) {
log.error("I/O or DB failed", ex);
} catch (IllegalArgumentException ex) {
// 单独处理参数问题
throw new BusinessException("Invalid input", ex);
}- 错误顺序示例：
catch (Exception e)写在catch (IOException e)前 → 编译失败 - 合并后异常对象类型是
Capture#1，无法调用子类特有方法（如SQLException.getSQLState()），需拆开处理 -
catch (Exception e)后面不能再跟其他catch—— 它已覆盖全部异常
try-with-resources 自动关闭资源的正确姿势
凡实现 AutoCloseable 接口的对象（如 FileInputStream、Connection、Scanner）都应优先用 try-with-resources，它比手动 finally 关闭更可靠：即使 try 块中抛出异常，资源仍会被关闭，且关闭异常不会掩盖主异常（会作为 suppressed exception 附加）。
启科网络商城系统由启科网络技术开发团队完全自主开发，使用国内最流行高效的PHP程序语言，并用小巧的MySql作为数据库服务器，并且使用Smarty引擎来分离网站程序与前端设计代码，让建立的网站可以自由制作个性化的页面。 系统使用标签作为数据调用格式，网站前台开发人员只要简单学习系统标签功能和使用方法，将标签设置在制作的HTML模板中进行对网站数据、内容、信息等的调用，即可建设出美观、个性的网站。
立即学习“Java免费学习笔记（深入）”；
try (BufferedReader reader = new BufferedReader(new FileReader("data.txt"));
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users")) {
String line = reader.readLine();
stmt.execute();
} catch (IOException | SQLException e) {
log.warn("Operation failed", e);
}- 资源声明必须在
try括号内，且只能是有效 final 或实际 final 变量 - 不要在
try块里重新赋值资源变量（如reader = null），会导致关闭空指针 - 若需访问 suppressed exception，用
e.getSuppressed()获取数组，但生产环境一般不依赖它做业务判断
catch 中该不该重新抛出异常，怎么抛
捕获异常后直接 throw e; 是常见反模式——会丢失原始栈轨迹。需要增强上下文或转换异常类型时，应显式构造新异常并传入原异常作 cause：
try {
parseJson(input);
} catch (JsonParseException e) {
throw new BadRequestException("Failed to parse JSON in request body", e);
}- 避免裸
throw e;或throw new RuntimeException(e);—— 前者未加信息，后者丢失原始类型 - 日志记录后继续抛出，用
log.debug("Ignored error", e); throw e;，但仅限明确要上抛的场景 - 若 catch 后决定“吃掉”异常（极少数情况，如清理临时文件失败可忽略），至少加注释说明理由，且不要静默吞掉
InterruptedException
异常处理不是越细越好，关键是让错误可定位、可恢复、不扩散。最常被忽略的一点：catch 块里别写复杂业务逻辑——它本该专注错误响应，而不是补救、重试或降级；那些该交给上层策略或专门的容错组件去做。
