库非常不错，但问题不是个好问题 about gsonfactory HOT 7 CLOSED

在DEV和QA阶段，可以配置成直接崩溃，把问题暴露出来，在线上环境，就可以默默的捕获，不要崩溃，同时上报接口错误日志，以便发现此问题。

from gsonfactory.

其实这个问题也是一个权衡。

从 To C 开发的角度来看，APK 一旦发版，审核上线，其版本控制权就再也不在开发者手上了，而是在用户手上，安装什么样的 APK 实际上是由用户决定的。

而与之对应的后端部分，其版本控制权一直都在开发者手上，就可以做到 随时上线，随时发版。

这时候显然应该由后端去负责进行这种 contract 不符的 bug fix；前端能做的，就是一个 兜底策略，解析出问题了，全部捕获，显示一个网络错误的界面，自然而然这个锅，就会到后端那里去处理，毕竟 网络错误 了嘛

而且，这种 Json 解析异常的问题，只要捕获住，APP 就不会崩，大佬还是在说崩的问题，我觉得确实可能没有好好看我上面写的东西。

从智能硬件和 To B 开发的角度来看，APK 的版本控制权其实一直在开发者手上，可以通过 IoT 随时向设备下发一个新的 APK 进行更新，这样的话，由谁来背锅都行；但是，讲道理的公司，应该还是最终责任方来进行背锅。

from gsonfactory.

这只是一个 repo motivation 的讨论，所以我自己关掉了；

当然还是希望大佬能就这个问题与我进行友好的讨论。

十分感谢！

from gsonfactory.

小伙子，每个人考虑的立场都不同的，你觉得好的东西别人未必觉得好，又或者说没有好坏之分，每个人只不过都站在自己利益最大化的角度上面想问题。

from gsonfactory.

Json 解析容错框架更多的是站在客户端开发人员上面，明明是后台返回的数据错了，但是就导致客户端就崩了，这口锅很容易就被扣到客户端上面，所以如果后台违反了事先约定好的数据格式，那么客户端在这种情况下就不应该崩溃。

from gsonfactory.

同样的想法。

最近的项目遇到一个问题：某个页面的接口偶尔会出现 json 解析错误，是偶尔出现！ dev 没有。 然后弹了个 toast，告诉系统繁忙，页面空白。
一直找不到原因，可能过一会就好了。

最近也是在纠结，要不要使用这个库。
如楼主所说，json这种问题，理论上来说，应该暴露出来，让后台修正。用了这个库就把问题隐藏了，后续可能很多问题都发现不了。
但是现在 iOS 好像是也用了个类似的库，后台json出错，iOS 不异常，就让我。。。。。。。

这样做感觉，实在不利于以后代码的维护啊。

from gsonfactory.

赞同,一般都是网络层统一处理,显示错误页面. 不过这个库的作用相当于把统一的错误处理给细化了,尽量让业务可用,也是一种可以选择的方式.

from gsonfactory.