把 try-catch-finally 与 try-with-resources 讲出实践味道，有一个可操作的公式：具体场景、关键决策、踩过的坑、最终效果。四样凑齐，面试官基本会记住这个回答；缺任何一样，回答都会显得单薄。每次面试讲到这两个结构，都有人栽在追问上——"finally 里的 return 会怎样""twr 为什么能保住主异常"。这篇把追问最密集的地方提前标出来。
机制拆解
先把结论放在前面：finally 无论 try 是否抛异常都会执行，是做资源清理的天然场所；但 finally 里若写 return 或抛异常，会盖掉 try 块里的结果或主异常，历史上大量事故源于此。try-with-resources（twr）则让实现了 AutoCloseable 的资源在退出时自动逆序关闭，并在关闭也抛异常时把主异常保留、把关闭异常挂到 suppressed，比手写 finally 安全得多。这题要答好，关键是把概念落到具体的工程场景里，讲出取舍和代价。
这些坑的正确绕法
最常见的坑是在 finally 里写 return。一旦 finally 有 return，try 块里即使抛了异常、或者明明 return 了正确结果，都会被 finally 的 return 无声覆盖——调用方拿到的是 finally 的返回值，try 里的异常像从没发生过。线上表现就是"方法返回了却带着错误数据，日志里却查无异常"。诊断极难，因为异常被"合法"地吞掉了。
其次是手写 try-finally 漏关其中一个流。在同时开输入流、输出流、网络连接的场景里，只要有一处 close 被遗漏或顺序错了，文件句柄或连接就持续上涨。长连接、大文件处理场景里，这类泄漏会缓慢把进程拖垮，表象是"运行几天后句柄耗尽"。twr 的出现就是为了解决这个：它保证所有资源都关闭，且顺序是声明的逆序（后开的先关），人不再需要手动对账。
还有一个更隐蔽的坑：finally 里抛异常会吞掉主异常。try 块抛了 A，finally 关闭资源时又抛了 B，如果 B 直接上抛，调用方只看到 B，真正的根因 A 丢失。twr 的聪明之处在于，它会把 A 作为主异常抛出，把 B 通过 addSuppressed 挂到 A 上，排查时 e.getSuppressed() 就能拿到完整链条。手写 finally 几乎没人会主动做这件事。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 手写 finally：关闭顺序错或漏关，且吞异常风险高
FileInputStream in = null;
try {
in = new FileInputStream("a.txt");
// ... 读
} finally {
if (in != null) in.close(); // close 抛异常会吞掉主异常
}
// try-with-resources：自动逆序关闭，保留主异常 + suppressed
try (var in2 = new FileInputStream("a.txt");
var out2 = new FileOutputStream("b.txt")) {
in2.transferTo(out2);
} catch (IOException e) {
log.error("copy failed", e); // e 是主异常，关闭异常在 getSuppressed()
}
这段代码值得盯三处：第一处，手写 finally 里 close 如果抛异常，会盖掉 try 块的主异常，且 in 为空判断稍有不慎就 NPE；第二处，twr 要求资源实现 AutoCloseable，编译器生成的关闭顺序与声明相反（后开的 out2 先关）；第三处，twr 在关闭也抛异常时保留主异常、把关闭异常挂到 suppressed，根因不再丢失。面试讲到这一层，基本就稳了。
这题在面试里怎么问、怎么答
"请简单介绍一下 try-catch-finally 与 try-with-resources，它们在 Android 开发中起什么作用？"定义开场、场景展开、案例收尾，按这个骨架答。重点是说清 finally 的"必执行"语义和 twr 的"自动关闭且保主异常"语义。凡是涉及 IO、数据库、网络连接这类需要显式释放的资源，twr 都是首选；finally 则用于那些不支持 AutoCloseable、或需要在异常和正常两条路径都做收尾的逻辑。
"它们的底层原理是什么？能不能详细说一下？"twr 是编译器语法糖：它把资源声明翻译成 try 块，并在隐式的 finally 里依次调用 close()，关闭顺序与声明逆序，且对每次关闭用 try-catch 包住、把异常挂到主异常的 suppressed 列表。这与手写 finally 的区别在于，编译器替你处理了"主异常 vs 关闭异常"的优先级。调用链上，资源的生命周期被严格约束在作用域内，出了花括号就关闭，不会发生"忘记关"的人为遗漏。
"在使用它们时遇到过什么问题？"先复现再修复：没有稳定复现路径的修复都是赌博，验证手段要提前设计。比如曾出现过"finally 里 return 导致异常被吞、上游以为成功"，复现方式是写一段 finally 强制 return 的代码观察返回值，修复是把 return 移出 finally、只在 finally 里做清理。又比如 twr 资源顺序错导致"先关输入流"使拷贝失败，修复是调整声明顺序。讲这类问题带上复现和验证，比空谈"要注意"有力得多。
"它们和相关的替代方案相比，有什么优劣？"选型时要把"手写 try-finally 漏掉其中一个流，长连接场景文件句柄持续上涨"这类代价摆到台面上，再决定是否引入。与手动管理相比，twr 几乎消除了遗漏关闭和吞异常两类高发问题，代价是要求资源实现 AutoCloseable（绝大多数 JDK 资源已满足）；与不关闭、依赖 GC 回收相比，显式关闭能及时释放句柄，避免资源耗尽。一句话：只要资源支持 AutoCloseable，就没有理由不用 twr。
关于 suppressed 异常，值得单独讲清 API 细节：Throwable.addSuppressed(Throwable) 把"被压制的异常"追加到一个列表里，getSuppressed() 返回它，打印堆栈时这些被压制的异常会附在主异常之后，排查时一目了然。这解决了"关闭资源抛异常会盖掉主异常"这个历史难题——过去手写 finally 几乎没人会主动保留关闭异常，导致根因被埋。twr 把这件事做成了编译器保证的行为，是它在工程上最值钱的地方。还要提醒一点：twr 的变量作用域仅限于 try 块内部，资源出了花括号即关闭，这天然防止了"忘记关"和"在资源已关闭后继续使用"两类错误。把资源声明收敛进 twr，比靠 code review 人盯人可靠得多。
再补一个细节：twr 里声明的多个资源，关闭顺序与声明严格相反——后声明的先关。这在"先开输入、再开输出"的场景里很关键：输出流先关，输入流后关，与手工关闭的顺序直觉一致，避免了"输出还没刷完就被关掉"的隐患。另外，close() 本身可能抛异常，twr 会把每个关闭异常都收进 suppressed 而非只保留最后一个，排查时 e.getSuppressed() 能拿到所有被抑制的异常。理解这两点，才算真正吃透了 twr 比 finally 强在哪里。
给正在准备面试的你
纸上读 try-catch-finally 与 try-with-resources 容易忘，写一次、复盘一次，理解才落袋。动手对比"finally 里 return"和"twr 保主异常"两种写法，把异常流向在脑中跑一遍，比背十遍定义都管用。面试中关于这两个结构的问题，关键在于能够从原理、应用、踩坑三个层面给出有深度的回答。
再补工程案例与踩坑——应用落点是把项目里所有手写流关闭改成 twr，并补一个"关闭抛异常时主异常不丢"的单元测试，从机制上锁死这类回归。
复习时别孤立刷题：HashMap 底层原理——数组、链表与红黑树的演进相邻知识点是一串的，面试常打包出现。
下一篇讲自定义异常与异常链：生产代码怎么设计错误，建议把两篇连起来看，效果翻倍。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：异常体系-Throwable：Checked-与-Unchecked-的边界
下一篇预告：自定义异常与异常链：生产代码怎么设计错误
有任何问题欢迎在评论区留言交流。
