Android 开发,如何写出符合规范的异常处理代码?

基础知识
Java 异常
异常层次结构
在 Java 中,异常明确的分为两种:Checked Exception 和 Unchecked Exception。下图中的红色部分表示 Unchecked Exception 异常,蓝色的表示 Checked Exception。

Checked Exception
Checked Exception 必须被显式地捕获或者传递,否则在编译期就会显示的报错。
一般而言,Checked Exception 指的都是不受程序直接控制的错误。它们通常都是由于与外部资源、网络交互而发生的,例如数据库问题、网络连接错误、文件丢失等问题。

Checked Exception 常是 Exception 类的子类。

Checked Exception 的例子如:ClassNotFoundException、IOException、SQLException 等。

Unchecked Exception
Unchecked Exception 即开发者不必显示的捕获或传递而在编译期是不会报错的。

编译器不会强制要求使用方对 Unchecked Exception 进行显示的捕捉。

Unchecked Exception:

RuntimeException 的子类。eg:NullPointerException、AritheticException、ArrayStoreException、ClassCastException等。
Error 的子类。eg:*Error、OutOfMemoryError等。
Kotlin 异常
Kotlin 的所有异常类都是 Throwable 类的子孙类,这点和 Java 类似,但是 Kotlin 中没有 Checked Exception,所以 Kotlin 中所有的 Exception 都是 Unchecked Exception,也就意味着编译器不会强迫捕获任何异常。

Android 开发,如何写出符合规范的异常处理代码?

背景
问题一:在什么情况下适合抛出异常?
平时大家在开发时,会有一些在执行逻辑或者参数不符合预期时,会直接抛出一个异常,如下代码比较常见:

public boolean open(xxx) {
    if (xxx) {
        xxxx
    } else {
        throw new IllegalArgumentException("xxxx");
    }
    return xxxx;
}

如果代码执行匹配上了异常逻辑,在运行时调用方没有捕捉相应的异常,应用就会直接崩溃,对用户造成不友好的体验。

问题二:捕捉异常的代码应该如何写?
我们平时开发时,对于需要捕捉异常的场景,我们又该如何规范的书写呢?比如下面的代码写的合理吗?

try {
    xxxx
} catch (Throwable e) {
    e.printStackTrace();
}

问题三: Kotlin 和 Java 混合开发的问题
Java 和 Kotlin 在对异常的设计理念就有差异,所以在互调时应该怎样对齐两者的差异?最大的差异是 Kotlin 没有 Checked Exception 这个概念,这样在项目使用 Kotlin 和 Java 混合开发时就会存在一些争议性的问题:

捕捉异常争议
在 Kotlin 调用 Java 代码时,如果 Java 抛出了 Checked Exception ,Kotlin 应该主动捕捉还是不主动捕捉?我们第一反应是应该捕捉,既然要捕捉但是在开发阶段 ide 又不会给予显示的提示,并且不捕捉在编译期又不会报错。

抛异常争议
Kotlin 在需要抛出异常的场景应该怎么写?只是把异常抛出来?抛出来,调用者又很难感知到异常,所以就存在代码命中相关异常崩溃的风险。

由于以上各种问题的存在,在认知层面所有开发者未达成一致的情况下,也就会存在 code review 时标准不一致,不规范的使用异常也会导致更多的线上崩溃,并且业内也没有一套比较可行的标准能直接使用,所以我们不得不针对这些问题制定一套行之有效的规则和流程来解决这些问题。

解决办法
对于 Java 和 Kotlin 异常的不一致,我们基于代码质量考虑,选择对齐 Java 的代码规范,所以 Kotlin 侧我们就定义类似 `
Checked Exception` 概念,对于需要显示提示出来的能力,借助 Lint 的能力实现(Kotlin 编译器不会强迫捕获任何异常)。

对于抛出异常,明确规定上层业务调用者不允许抛出异常,仅 API 提供方在不得不抛出异常的场景,才允许抛出异常,并且得抛出 Checked Exception。

对于捕获异常,原则上捕获是为了处理它,应该加上必要的处理逻辑,在捕获只是为了兜底的场景(可能会发生崩溃)提供对异常上报的工具类。其他使用规则对齐业内的标准。

最后对于所有制定的规则,提供 Lint 检测能力,在 MR 流程中进行卡点,保证代码的正确性。

如果你想开发小程序或者app的话,可以通过第三方专业开发平台,来帮助你实现开发需求:厦门在乎科技-专注厦门小程序开发公司、app开发、网站开发

上一篇:wp2vite的妙用,让webpack项目支持vite


下一篇:带你彻底搞懂 Redis 14大应用场景!