java中try-catch应只包裹明确可能抛异常且能处理的代码，避免过大或过小；受检异常必须处理，非受检异常慎用throws；日志需用slf4j记录完整上下文并脱敏；自定义异常依是否强制调用方处理选择继承exception或runtimeexception。
Java中try-catch到底该包多大范围？
包太小，异常漏捕获；包太大，逻辑耦合、掩盖真实问题。关键不是“要不要包”，而是“包哪几行——且只包那些真正可能抛出异常、且你有能力处理的代码”。
常见错误现象：NullPointerException在catch块里被吞掉，日志没打，上层完全不知道调用失败；或者把整个方法体塞进try，结果IOException和IllegalArgumentException混在一起处理，语义全乱。
- 只包裹明确会抛受检异常（
IOException、SQLException）或你主动预期的非受检异常（如JsonProcessingException）的调用点 - 避免包裹纯计算逻辑（比如
Math.abs(x)、list.size()），它们不会抛异常，加try纯属干扰阅读 - 如果调用链里多个步骤都可能抛同类型异常（如连续读三个文件），优先拆成独立
try-catch，便于定位具体哪一步失败
什么时候该用throws而不是try-catch？
不是所有异常都要当场处理。把异常往外推，是分层协作的基础——让更上层、更了解业务上下文的代码决定怎么应对。
使用场景：DAO层读数据库失败，抛SQLException；Service层不自己重试或降级，而是声明throws ServiceException；Controller层才决定返回500还是兜底数据。
立即学习“Java免费学习笔记（深入）”；
- 受检异常（
Exception子类但非RuntimeException）必须显式处理，要么catch，要么throws——别用catch空吞再throw new RuntimeException(e)来绕过 - 非受检异常（
RuntimeException及其子类）原则上不该在方法签名写throws，除非是自定义业务异常（如InsufficientBalanceException），且你希望调用方明确感知 - 注意JDK 7+的
AutoCloseable资源自动关闭机制，try-with-resources里的资源声明本身就会隐式throws，别重复写
catch块里只写e.printStackTrace()有多危险？
它把堆栈输出到System.err，而生产环境通常重定向或忽略这个流——等于什么都没留。更糟的是，它掩盖了异常类型和上下文，调试时只剩一句“出错了”，毫无线索。
性能影响：频繁调用printStackTrace()会触发Throwable.fillInStackTrace()，开销不小；而日志框架（如SLF4J）默认懒加载堆栈，更轻量。
- 统一用日志框架记录，例如：
log.error("Failed to parse config file", e) - 不要只记异常名（
e.getClass().getName()），要带原始消息和完整堆栈 - 敏感信息（如密码、token）不能出现在日志里——捕获后先脱敏再记录，或用
log.error("Auth failed, user: {}", userId)代替拼接完整异常消息
自定义异常该继承RuntimeException还是Exception？
取决于你是否想强制调用方处理它。Java的设计本意很清晰：受检异常用于“程序本可预见、且调用方大概率需要干预”的场景（如文件不存在）；非受检异常用于“程序缺陷或不可恢复的错误”（如空指针、数组越界）。
容易踩的坑：把所有自定义异常都设为受检，结果满屏throws，反而让真正重要的异常信号被淹没。
- 业务异常（如
OrderAlreadyShippedException）建议继承RuntimeException——它是业务规则违反，不是IO或配置错误，调用方不处理也应让流程失败暴露问题 - 只有当你确定某类异常**必须被上层显式决策**（比如支付超时，要走人工复核流程），才设计为受检异常
- 无论哪种，都提供含参构造函数，支持传入
cause，保证异常链不断：`super("Invalid payment method", cause)`
真正难的不是语法，是判断“这个异常，此刻该由谁、以什么方式响应”。写catch前，先问一句：我在这里能做比抛出去更有价值的事吗？
