Kotlin中runCatching配合also是否等价于try-finally结构？

结论：两段代码不完全等价，你关注的「清理代码一定执行」的需求可以被满足，但执行顺序、异常传播行为和Java原版有差异，可维护性取决于具体场景。

相同点：清理逻辑的执行有保障 #

runCatching会捕获块内所有非虚拟机致命级别的Throwable（和Java普通try-catch能捕获的异常范围一致），不管业务代码执行成功还是抛出异常，后面的also块都会被执行，这一点和Java的finally效果完全一致，你的清理代码不会被跳过。

核心差异点 #

1. 执行顺序和Java原版相反
   你写的Java代码执行顺序是：业务代码→触发异常先走catch处理→最后执行finally清理。
   而你贴的Kotlin代码执行顺序是：业务代码→先走also清理→有异常再走onFailure处理。
   如果你的异常处理逻辑依赖业务代码产生的中间资源（比如要读取临时文件内容上报错误），提前执行清理会直接导致异常处理逻辑失败。要对齐Java的顺序，调整链式调用的顺序即可：

runCatching {
  // ... Run some code
}.onFailure {
  // ... Handle exception
}.also {
  // ... Cleanup code
}

2. 异常传播行为不同
   Java的catch块如果没有主动重抛异常，异常就会被消化；如果你的Java代码是要把异常继续向上抛的，直接在catch最后加throw ex即可。
   而runCatching会把所有捕获的异常封装进Result对象，只要你不主动调用getOrThrow()之类的方法，外层代码永远感知不到块内发生过异常，相当于默认吞掉了所有异常。如果你的业务逻辑需要异常向上传播，要额外加抛出逻辑。

可维护性建议 #

如果只是简单的清理+异常处理场景，直接用Kotlin原生的try-catch-finally写法可读性最高，和Java逻辑完全对齐，没有理解成本。runCatching的链式写法更适合需要返回执行结果、后续要对成功/失败结果做流式处理的场景，没有必要为了用Kotlin特性刻意改写法。

内容的提问来源于stack exchange，提问作者Itay Polack-Gadassi