当前位置: 首页 > 资讯 >

Day 17 - Error Handling 错误处理

前言

错误处理往往是最容易被忽略的一块,因为

  • 程序运行顺利,那当然不用考虑 error case
  • 程序被测出 bug,通常是程序码里面有问题,QA 会催着你赶快去修,修完之後就回到第一点,那个「运行顺利」的版本了,好像又不用错误处理了

这样到底什麽时候要错误处理?

为了方便讲解,我们先来复习一下错误处理的必须武器 try catch,如果你已经很熟了可以跳过这一段:

try/catch/finally

try/catch/finally 属於流程控制的逻辑区块(跟 if/else 一样),以下分别介绍:

openFile();
try {
  writeFile(theData); // 可能产生例外
} catch(e) {
  handleError(e); // 处理可能发生的例外
} finally {
  closeFile(); // 总是在 try 结束後关闭档案
}
  • try
    此区块是主要的程序执行区块,只要在这个区块的任何一行抛出错误(无论有没有用到 throw),就不会继续往下执行,而是跳到 catch 区块第一行开始执行。
  • catch
    此区块可以在错误发生时,自动捕捉进来这个区块,会进来代表「出代志」了,通常会针对错误做一些对症下药或善後处理,起码可以确保程序不会直接死当。
  • finally
    此区块是无论如何都会执行到的,trycatch 区块执行完就会进来,用来处理一些无论有没有错误都要做的事情(比如把 loading 关掉、写 log 等)。

错误的种类

来谈谈错误的种类,了解一下「错误」到底是什麽?才会知道该怎麽处理它:

程序开发者的错误(programmer errors):

即程序本身的 bug,错误是程序本身没写对造成的。常见的例如:

  • 语法错误(syntax error):少括号、关键字拼错等
  • 取值错误(reference error):变数、函式忘记宣告就使用
  • 类型错误(type error):在 Number 类型的变数使用 Object 的函式

这类型的错误代表与开发者的意图背道而驰,因此没有悬念,就是一定要把它改对,通常透过开发人员工具可以轻松找到原因。

运算的错误(operational errors)

在程序本身没有 bug 的情况下,错误发生在系统本身,通常是程序与外部互动下发生,外部可能是使用者、网路远端、档案系统。常见的例如:

  • 使用者输入极端值
  • 网路连线问题
  • 记忆体超出负荷

这类型的错误代表,通常在使用者「预想」情况下,程序是可以正常运作的,但是如果:

十笔资料可以跑,那十万笔呢?
都市可以跑,那偏乡地区呢?
json 档案可以处理,那 xml 呢?

因此,其实这类型的错误不太算是「错误」,毕竟部分的 case 都还是可以运作的,或许比较适合称呼为例外(exception)。

这类型的错误处理起来就复杂许多,需要对症下药,

  • initial:针对首次使用服务可能会没有初始值的问题,可以视情况先做 initial 动作。
let file;
try {
    file = readFile(filePath);
} catch (err){
    file = createFile(filePath);
}
console.log(file);
  • retry:针对网路连线类型的问题,可以限制次数 retry。
let retryCount = 0;
const retryMax = 3;
do {
    try {
        console.log(retryCount);
        // ...
        // 可能失败的 code 放这 
        // ...
        break;
    } catch (err){
        console.log(err);
        retryCount++;
        if (retryCount >= retryMax) {
            // 超过 retry 次数强制跳出
            break;
        } else {
            // 还没超过可以再试一次
            continue;
        }
    }
} while (true);
  • unknown:面对未知的问题,都应该要有最後一道防线,发生例外时记下 Log,跳出 toast 讯息提醒前端,并关掉 loading 让使用者仍然可以进行其他操作等。
setLoading(true);
try {
    // ...
    // 可能失败的 code 放这 
    // ...
} catch (err){
    logToDB(err);
} finally {
    setLoading(false);
    toast('系统不稳,请稍後再试');
}

我可以用 if/else 来处理错误吗?

未知的问题在 catch 处理很合理,有一些已知的问题也放在 catch 处理,但既然我都知道这边有可能会出问题了,为何不乾脆用 if/else 判断处理?

这个问题其实我也觉得稍微模糊,我的想法是,需要先去定义出,catch 究竟要接收什麽?是所有取不回资料的状况吗?还是针对非正常流程的处理?针对不同的目的,应该使用不同的处理,以下是我的一些想法

适合放在 catch 处理的:

  • I/O 时发生错误,比如: 读写档案、fetch 资料途中,发生例外情况
  • 无法完成预期的工作,比如: 想要读取登入後的画面,但因为还没登入导致的错误
  • 内部错误,比如後端自己死掉,或是前端传送错误参数

不适合放在 catch 处理的(可以用 if/else 处理):

  • 查不到资料(而非查资料失败)的情况,比如: 资料库查询,query 不到东西的情况下,需要处理空值,而非抛出错误。
  • 询问类,比如: 手机要读取联络人清单的权限,当回传的结果是 false,也就是使用者不授予权限时。

但这也不是硬性规定,单纯是不同的想法导致不同的设计,甚至不同的 API 在处理错误的状态也都不尽相同,因此笔者认为,只要整个 app 在面对错误是一致就可以了 (比如查无资料要嘛都放 else,要嘛都放 catch)。

为什麽错误处理是最容易被忽略的一块

回归到开头的问题,为什麽错误处理往往是最容易被忽略的一块?

  1. 相对陌生
    网路上的教学影片,实体课程里面的教材,甚至 StackOverflow 等技术讨论论坛,绝大多数的篇幅也都是在教如何「写出你想要的 feature」,而非「修补可能发生的 exception」。
  2. 黑天鹅
    解决问题的第一步,是发现并重现问题,这样修好了才知道自己不是蒙到。但很多错误是在特定环境才会发生,比如直接操作 A 没事,但先操作 B 再操作 A 就会错误。甚至要是极端情况(极短时间、大量资料)才发生,因此光是「产生」这种例外就很困难了。
  3. 看不见的防护网
    就算真的把这些难缠的问题搞定了,成果也很难被看见,因为对於使用者/PM 来说,发生错误令人烦躁,但没发生错误却像是基本,也许只有 20% 的时间会发生错误,但我们却需要花费 80% 的时间去处理。

类比来说,其实错误处理很像是现实社会中的「保险」:

  1. 相对陌生
    许多人常常「主动」去自学股票、网页、厨艺等学问,而保险也是一门学问,但有趣的是,大部分接触到保险的人属於「被动」接触,也就是迫於需要,不得不去理解,往往是生活中出现漏洞才会想到。
  2. 黑天鹅
    大家都知道保险重要,因为永远不知道明天跟意外哪个先到,尤其意外愈严重愈重要,但严重的意外本来就很少见,当我们意识到时,往往已经深陷泥沼。
  3. 看不见的防护网
    即便我们真的把保险买齐了,医疗意外储蓄一应俱全,甚至连长照险都超前部署,生活品质短时间仍然不会有变化,毕竟保险确保的是,即便意外发生,仍然确保你有一定的生活品质。

当然啦,错误处理跟保险还是有很多细节、情境的不同,不可完全类比,这边只是笔者有感而发XD,觉得有些事情,我们在写程序的时候会碰到,在现实生活中也会碰到。

结语

错误/例外处理是很多开发者不太想去碰的一块,很容易只关注在「正常」,而比较少考虑「异常」。

市场上大部分的商业专案、产品,PM 当然也都是要求先有功能,毕竟没功能的话,就算有一堆 try catch 也是枉然。

但正是因为「少而重要」,才能体现出价值,如果能够在这点更谨慎,无疑是朝向「更好」的 developer 迈进!

愈深的洞穴里
藏着愈闪耀的宝石

参考资料

MDN - 例外处理


相关文章:

  • [Day 28] Partitioning (2) - Partitioning and Secondary Indexes
  • #14 No-code 之旅 — 怎麽利用 Chakra UI 去做 React 元件客制化?
  • 【D21】修改食谱#2:根据市价,模拟小台改价
  • 如何衡量万事万物 (4) 校准过度自信的估算
  • DAY27 - 建议避免的CSS命名规则
  • Day17 在React 中使用Material icons
  • DAY05 资料分析的步骤
  • 参考监视器的非必需属性-高凝聚力(High cohesion)
  • Day29-Go gRPC(下)
  • [Day05] pod service node kubectl
  • D14/ 怎麽做拉动的操作? - Draggable Gesture
  • Day 24 可程序设计间隔计时器
  • 26/一起成为国际研讨会讲师!!!(投稿篇)
  • Day 02 | Laravel Livewire 基本介绍
  • 强型闯入DenoLand[34] - 浅谈跨来源资源共用(CORS)与解决办法
  • 日本虚拟信用卡预付卡礼品卡大全
  • VPS优惠信息:阿里云/限时活动/新用户1C2G1M/69元/年起
  • Google Play Store报错DF-DFERH-01怎么办
  • SiteGround域名转移教程:如何转出SiteGround域名
  • WordPress 5.7 的 Robots API 和 max-image-preview 指令
  • SiteGround主机评测和推荐
  • VPS测评:on9host/香港WTT DIA+BGP/30M/三网直连/月付7.8刀起
  • 海外营销周报:谷歌广告将推出动态排除列表,报告显示2020年美国数字广告营收增长12%
  • 一键脚本:Aria2+Aria2Ng+OneIndex | 自动上传OneDrive
  • 最新虚拟信用卡无限开卡渠道大全
  • Vultr / Digitalocean开通教程和购买教程,Vultr / Digitalocean如何切换IP教程方法
  • Akaxin:开源社交软件/加密聊天/打造你自己的社交产品
  • VPS评测:阿里、腾讯、百度、京东VPS最低配理性对比
  • 搬瓦工VPS注册购买教程 – 支付宝BandwagonHost购买方法教程
  • WordPress 5.7 引入函数来检查文章是否可以公开查看