能否用异常处理网络错误？密封类与异常处理优劣对比

很多开发者在Retrofit、Ktor这类网络库中都会用类似ApiResponse的密封类处理请求结果，这种方式和直接用异常传递错误各有优劣，下面具体分析：

密封类ApiResponse的优势 #

• 编译期安全保障：密封类的子类是固定的，用when表达式处理时，编译器会强制覆盖所有分支（Success/Failure），彻底避免因遗漏错误处理导致的运行时崩溃。
• 结构化错误信息：Failure可以封装各种业务相关的错误细节——比如HTTP状态码、用户友好提示、重试标识、底层异常等。UI层拿到后不用在catch块里反复判断异常类型，直接用封装好的信息做处理。
• 异步流稳定性：在Flow、协程这类异步场景中，失败是流的正常元素，不会中断整个数据流。比如分页加载时某一页失败，流还能继续推送后续页的结果；而异常会直接终止流，需要额外逻辑才能恢复执行。
• 跨层语义清晰：ApiResponse传递的是业务结果状态，而非技术层面的异常。UI层不用关心底层是网络超时还是服务器错误，只需要处理“成功显示数据”“失败显示提示”这两种业务逻辑，代码更聚焦业务。

异常传递错误的劣势（除了易遗漏处理） #

• 语义错位：异常的设计初衷是处理意外的、不可预期的错误，但很多网络错误是业务预期内的（比如401未授权、404资源不存在）。用异常处理这类场景，会把业务逻辑和技术错误混在一起，代码可读性差。
• 异步场景破坏性：在协程或Flow中，异常会向上冒泡传播，如果没有在合适的层级捕获，可能导致整个协程取消、流终止，甚至影响其他关联的异步任务；而密封类的失败状态不会中断执行流程。
• 信息传递繁琐：虽然可以自定义异常携带额外信息，但需要继承Exception并添加字段，使用时还要强制类型转换；密封类的Failure可以直接封装所有需要的信息，调用时直接访问属性即可，更直观高效。
• 测试成本高：测试错误场景时，用异常需要编写捕获异常的断言逻辑；而用密封类只需要断言返回的是Failure实例并验证其属性，测试代码更简洁直观。

关于样板代码的解决思路 #

Clean架构各层确实可能需要定义类似的结果类，但可以通过泛型复用基础结构，比如定义通用的Result<out T>密封类，各层只替换泛型参数（ApiModel/DomainModel/UiModel），再通过映射工具（如Mapper）处理模型转换，就能大幅减少重复代码。

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