PS: 本文在开源项目:https://github.com/xieyuliang/Note-Android中已收录,里面包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等,资源持续更新中……
前文指路↓↓↓
实际生产中的 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开发中,应该通过对相关错误进行分类,来决定采用异常交互还是返回码交互。
最后
说一千道一万,不如自己去行动。要想在移动互联网的下半场是自己占有一席之地,那就得从现在开始,从今天开始,马上严格要求自己,既重视业务实现能力,也重视基础和原理。基础夯实好了,高楼才能够平地而起,稳如泰山。
最后为了帮助大家深刻理解Android相关知识点的原理以及面试相关知识,这里放上相关的我搜集整理的24套腾讯、字节跳动、阿里、百度2020-2021面试真题解析,我把技术点整理成了视频和PDF(实际上比预期多花了不少精力),包知识脉络 + 诸多细节。
还有 高级架构技术进阶脑图、Android开发面试专题资料 帮助大家学习提升进阶,也节省大家在网上搜索资料的时间来学习,也可以分享给身边好友一起学习。
网上学习 Android的资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!
架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!**