鸿洋推荐：实际生产中的-Android-SDK开发总结（二）(1)

实际生产中的 Android SDK开发总结（一）https://www.jianshu.com/p/ff9362d243a2

Exception or ErrorCode

一、前言

本章介绍了Java/Android中的异常以及在SDK开发中是如何根据异常的特性进行融合设计的思考。

注意，本章并不涉及详细地异常介绍以及异常发生后代码执行地顺序问题，而是基于异常的基本特性与职责边界，结合业务开发的实际情况，试图探讨抛异常与错误码的选择。

二、异常的概念

首先，我们来认识一下异常：

异常是指在程序运行期间发生的意外事件，它会中断程序（当前方法或作用域）正常执行的流程。

异常的层次

• Checked Exception，比如最常见的IOException，这种异常是指需要调用处显式处理的类型，要么用try catch捕获，要么用 throw 再抛出去；

• Unchecked Exception指的是所有继承自Error（包含自身）或者RuntimeException（包含自身）的类，比如我们常见的NullPointerException就属于这类。这些异常不强制在调用处显式处理，但是也可以通过try catch处理；

• Throwable是Exception和Error的父类。

2.1、APP开发者看待异常的角度

在APP的开发中，似乎我们总是被动的根据编译器的提示编写异常代码，只是为了让编译器通过。为什么编译器跟我们过不去？因为这些提示都是因为对于的操作抛出了Checked类型的异常，需要手动显式进行处理。

在Java开发中，NullPointerException，有部分人简称NPE，是每个开发者都很熟悉的异常，也是让人深恶痛绝的异常。

Java程序员：要么正在debug NPE，要么就在debug NPE的路上。

2.2、SDK开发者看待异常的角度

在SDK开发中，除了要面临APP开发中那些对异常的处理，还需要充分考虑被异常中断了的那些逻辑对整体交互流程产生的影响。

SDK自身的逻辑与APP密不可分，假如因为SDK内部发生的异常，中断了SDK内部流程，而又未告知APP这显然是不可接受的。因此，我们必须谨慎处理SDK内部发生的异常，原则是不应该把异常内部消化，而应该向外抛出，以同样异常的形式或者自定义的返回码。

2.3、Exception or ErrorCode，这是一个问题

在SDK的逻辑设计中，既可以通过异常告知开发者，也可以通过返回码告知开发者，那么如何选择呢？下面我们通过两个例子来探索处理的方式

• 场景1：在SDK的入参中，需要APP传入手机号码，并校验参数合法性

• 场景2： 在SDK内部，需要获取APP ID并进行白名单校验

这两种场景下，都需要在SDK的调用流程中处理并反馈，而反馈可以通过返回码，也可以直接抛异常（系统内置异常或自定义异常）孰好孰坏？

笔者认为，在我们实际的SDK开发中，应该通过对相关错误进行分类，来决定采用异常交互还是返回码交互。

自定义异常是一种比较“重”的告知方式，因为异常意味着中断。返回码是一种比较“轻”的告知方式，也是最不容易引起开发者重视的告知方式。

总结

算法知识点繁多，企业考察的题目千变万化，面对越来越近的“金九银十”，我给大家准备好了一套比较完善的学习方法，希望能帮助大家在有限的时间里尽可能系统快速的恶补算法，通过高效的学习来提高大家面试中算法模块的通过率。

这一套学习资料既有文字档也有视频，里面不仅仅有关键知识点的整理，还有案例的算法相关部分的讲解，可以帮助大家更好更全面的进行学习，二者搭配起来学习效果会更好。

部分资料展示：

有了这套学习资料，坚持刷题一周，你就会发现自己的算法知识体系有明显的完善，离大厂Offer的距离更加近。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！**