在日常的研发过程产品质量的产生本身内部代码逻辑，导致的异常的占比较高，而因为数据产生的一异常比例较低，常见于客户端与服务端的通讯产生的数据和客户端本地存储的数据产生的异常，这类异常复现的成本也相对的高一些，比如需要产生数据交互的行为，或产生数据的存/取的行为，甚至还是版本兼容问题导致，复现的周期比较长。
一般来讲，常见的异常的产生有以下几种情况
- 空数据：下发的数据中部分的节点数据为空，解析出来的数据和对象，对于空数据的处理兼容性不足导致异常。
- 编解码不对：编码问题常见于文本的编/解码（中文/英文），特定格式的编/解码，如URL，媒体数据格式，导致内容加载过程出错，异常。
- 格式不对：因数据格写的书写差异，导致配置项中的数据解析出错。如数据的版本不兼容，如原本为字典的数据配置为数组。
- 特定场景异常：数据在开发及测试过程没有发现异常，但在线上某个特定的环境会产生异常，如某个脚本的逻辑分支异常处理不够全面，或者某个服务器/机房存在异常。
对于框架层面，可以进行一些策略上的调整，和能力上能拆分，规避并优化上述的云端的数据的下发，导致其它异常产生。
- 延时更新/读取：配置文件的更新及读取，不在APP启动阶段发起，这样有两个好处，1）对于启动阶段的任务进行裁剪，启动速度快；2）对于更新阶段产生的异常，不会影响APP的启动，避免出现每次启动阶段都产生异常的情况。
- 状态唯一：状态唯一有两层目标，1）配置文件已经更新新版本成功，新版本的能力，应该在下次APP启动再生效；2）配置相关的状态变更应该是最早，并且是只有一次。否则的话需要建立状态变更通知的机制。
- 数据校验：数据的效验包含数据的完整性效验、数据的有效性效验，数据类型的效验等等，数据从云端下发，然后存储到本地，有数据并不代表数据就是对的，数据可以解析，数据可以支持业务按预期的运行，这样数据才算是有效的。或者是本地的数据格式，在产品升级过程出现了数据版本不兼容，同样也需要考虑。
- 异常上报：异常上报可以分为数据解析的过程产生了异常上报和配置加载到业务中运行时产生的异常上报。对于从云端下发的数据的处理的过程需要进行异常的捕获，同时你有在使用的过程当中，有关配置部分的逻辑，同样也是需要进行异常捕获。当异常产生之后上报云端，这样可以及时的发现一些错误的配置，及时进行止损。
- 端内回滚：当最新的配置下发到客户端，在解析或者使用的该配置数据过程产生了异常，要么当前的功能不可用，要么是直接产生了异常。这两种情形，对于用户来说都是功能，没有达到预期，理想的状态是当加载新配置数据时，产生了异常。这是应该恢复前一版本的配置，为用户继续使用。结合异常上报的能力，在对新配置数据进行修改一下发。
- 安全模式：记得刚接触计算机时使用的是Windows98的系统，有时候系统蓝屏了，重新启动的时候会提示进入安全模式，这种模式下的第一感觉就是显示器的分辨率极低，用起来体验极差，当时还不理解为什么要有安全模式。当系统出现一些特定级别的异常时，再次打开App只运行核心功能，这样可以规避此前的异常的再次产生，当App打开了有关于异常的日志也可以提交到云端，以被研发人员进行相关的分析及优化。
具备了这些能力之后，对于非预期的数据问题，基本上可以得到有效的异常产生，客观的讲，数据的产生是自动化的，长期来看是稳定的，异常通常与能力变动相关。而数据的产生是人工的，是来自于第三方的，那长期来看就是风险，因为缺少约束的手段，数据是黑盒，这时对于数据的不置信处理是有必要的。特别是在特定的case，使用特定的约定时，需要有基于这个case可能的变种实现兜底的方案。
