承接上一篇《单向数据流实践：State 与 Event 分离》，上一篇解决了「数据怎么从下往上流」，但没有解决「出错时这些数据怎么表达」。很多项目的错误处理是这样的：Activity 里try-catch一次，ViewModel 里try-catch一次，Repository 里try-catch一次，每个catch里各写各的 Toast，最后用户看到三个 Toast，而真正的错误原因被埋在最内层。结论先行：统一异常层的价值不是「少写几行 try-catch」，而是把「错误」从「散落的控制流」变成「可分类、可统计、可测试的数据」。好的错误架构必须回答四个问题：错误在哪一层被识别、在哪一层被转换、在哪一层被展示、由谁决定展示什么。一、四个问题定位错误处理的职责职责归属层理由识别：把底层异常翻译成有业务含义的类型数据层 / 领域层只有这里知道「HTTP 404」意味着「资源不存在」转换：把技术异常转成对用户友好的文案领域层或专门的映射器文案策略与业务绑定，不该散在 UI 
长河君 · 2026/11/6 5:16:58 · 阅读 1.2k 第319篇 错误处理架构：统一异常层设计
承接上一篇《单向数据流实践：State 与 Event 分离》，上一篇解决了「数据怎么从下往上流」，但没有解决「出错时这些数据怎么表达」。很多项目的错误处理是这样的：Activity 里try-catch一次，ViewModel 里try-catch一次，Repository 里try-catch一次，每个catch里各写各的 Toast，最后用户看到三个 Toast，而真正的错误原因被埋在最内层。结论先行：统一异常层的价值不是「少写几行 try-catch」，而是把「错误」从「散落的控制流」变成「可分类、可统计、可测试的数据」。好的错误架构必须回答四个问题：错误在哪一层被识别、在哪一层被转换、在哪一层被展示、由谁决定展示什么。一、四个问题定位错误处理的职责职责归属层理由识别：把底层异常翻译成有业务含义的类型数据层 / 领域层只有这里知道「HTTP 404」意味着「资源不存在」转换：把技术异常转成对用户友好的文案领域层或专门的映射器文案策略与业务绑定，不该散在 UI