为什么SignalR推荐在流处理场景中使用finally块传播错误

规范背后的核心设计原因 #

• 保障Channel生命周期的确定性：SignalR流式传输依赖Channel作为服务端到客户端的异步数据缓冲区，只要Channel未被显式关闭，客户端的流订阅会话会一直保持存活，长时间占用服务端连接资源、客户端内存资源，甚至触发超时异常。而finally块的执行有强保障——无论try块内的业务逻辑是正常执行完成、提前return，还是抛出任意类型的异常，finally块都会被执行，从根源上避免Channel泄漏。
• 统一错误传递与流收尾逻辑：流的结束状态有两种：正常完成、异常终止，两种状态都需要给客户端明确的结束信号，把这部分逻辑统一放到finally块中，可以避免正常流程和异常流程的收尾逻辑不一致的问题，降低代码维护成本。

与直接在catch块中执行关闭操作的核心差异 #

• 正常执行场景的覆盖问题：如果仅在catch块中关闭Channel，当业务逻辑没有抛出异常、正常执行完成时，catch块不会被触发，Channel永远不会被关闭，客户端会一直等待流数据，直到连接超时。
• 异常漏处理的问题：如果catch仅捕获了指定类型的异常，业务逻辑抛出未匹配的异常类型时，catch块不会执行，Channel还是会出现泄漏。
• 异常栈保留的差异：如果在catch块中关闭Channel时触发了新的异常，原本的业务异常会被新异常覆盖，导致根因丢失；而在finally块中处理关闭时，原始业务异常的调用栈会被完整保留，更便于问题排查。
• 逻辑一致性的差异：如果要同时处理正常结束的流关闭和异常结束的流关闭，在catch块写一遍关闭逻辑，还要在try块末尾再写一遍，重复逻辑更容易出bug，统一在finally块处理只需要写一次逻辑，更可靠。

内容的提问来源于stack exchange，提问作者Kent Boogaart