这是一个创建于 550 天前的主题，其中的信息可能已经有所发展或是发生改变。
我觉得应该在 sdk 处理异常，其他人直接拿到处理之后的结果直接用就行了。 组长觉得应该将异常处理交给使用 sdk 的人
 |
1
renfei 2023-05-25 16:42:05 +08:00
SDK 无法处理所有的异常
比如你传入的账号密码错了，报了个 401 错误，我帮你处理了异常，返回个 null 你外部调用死活只接收到 null ，你作为调用者你懵逼不 |
 |
2
xuanbg 2023-05-25 16:45:20 +08:00
SDK 当然不处理异常啊。多管闲事会要命的啊
|
 |
3
thinkershare 2023-05-25 17:02:02 +08:00
当然是应该将异常传递给最终 SDK 的消费者，主要是看异常是谁制造的，谁制造的交给谁处理。因为异常就是个简化的通知机制，如果你尝试糅合异常和 Result 这 2 种消息传递机制，只会给自己制造更多痛苦。如果调用方是最终消费者(无法理解你系统的内部逻辑），那可以考虑返回返回一个稍微包装的友好异常。
|
 |
4
x77 2023-05-25 17:13:40 +08:00
你组长是对的，谁产生的异常谁处理，SDK 是个被动模块它主动去处理异常（极少数 SDK 内部产生的异常除外）会让增加耦合度
|
 |
5
dzdh 2023-05-25 17:20:14 +08:00
你不能不处理也不能全部处理
最近正巧也在整内部的 sdk ，跨多个系统，多个系统的输出格式有几个是不一致的。 这种情况就需要 sdk 在针对这几个服务的调用时拿到对应格式的响应并处理整理成统一的响应格式，还有错误比如有的是 data.errors!=null ，有的是 data.code ==401 。 那么 sdk 要自己二次封装处理，统一抛出异常给调用方，调用方无须关心这几个服务的原来的输出结果。 至于网络异常、调用逻辑异常，服务端的业务异常，都应该经过 sdk 统一二次处理（统一收集错误信息和调用栈）后再抛出，处理不是屏蔽，是整理和封装 |
 |
6
EddieWang OP 我之所以想要在 sdk 里面处理，是因为调用方其实不是很关心报错的具体内容。只需要拿到结果判断就好了。
当然最后还是交给调用方处理了准备 |
Select Language