从问题错误处理中开始,是那种在它咬你之前似乎无关紧要的东西之一。
在我职业生涯初期,我写了代码 检查每个步骤的错误,但处理的不一致。
有些功能回归,另一些则放弃例外,少数只是记录下来并继续进行。
结果?
一个调试的噩梦 真正的问题 被埋藏在防守检查层。
经过多年的维护和系统建设,我决定了几种模式,使错误处理具有可预测性和可扩展性.
这是可行的。
第1模式:失败快,但大声失败 最糟糕的错误是沉默的错误。
当某事出错时返回的函数往往在后期导致密码错误,远离实际原因.
相反,应及早验证投入,并立即提出说明性例外。
这种模式迫使调用者在故障点处理出错,而不是倒下5个堆放框.
它还使你的功能合同明确:如果你通过不良的数据,你得到一个即时,清晰的信号.
图案2:对预期失败使用结果对象 并非所有错误都是例外的。
网络请求可能失败,文件可能不存在,用户输入也可能无效.
对于这些预期的失败,例外是过度杀伤。
它们打断了控制流动,使幸福的道路难以走入.
取而代之的是,使用一个明确带值或出错的结果对象。
呼叫者在使用该值前必须检查.
这使得潜在故障在类型签名中可见并可以防止意外的未处理出错.
图案 3: Async 流量集中处理出错 在Aync代码中,错误可以滑过,如果你不到处捕捉它们.
将错误处理集中到应用程序或服务的边界上,而不是将每个错误都包入尝试/捕获物中。
如果使用Express,甚至可以使用Aync包装来避免在每个路线中重复尝试/捕获.
然后一个处理出错的中间软件负责记录和一致的反应。
图案 4: 保留出错的背景 当你发现错误并重新扔出一个新的时,不要丢失原始的堆栈跟踪.
把它包装好 现代JavaScript支持这个选项,它保留了原来的错误.
这使得您在调试时既能有高层次的描述,又能有低层次的细节.
模式5:不要吞咽出错 寂静地"空"接取块是一种代码嗅觉.
如果遇到错误,请用它做点什么:登录它,重投它,或者转换成有意义的反应.
吞噬错误隐藏了虫子,使系统在不出现时显得健康.
Putting It All Together 一个实用的方法就是对错误进行分类: 程序员错误:bug like null references.
失败的快速,崩溃的过程,修复代码.
操作错误:如网络超时.
使用结果对象或重试 。
用户输入错误:验证失败.
早归有明相传.
通过分离这些,避免过度工程,同时保持代码的弹性.
在下一个工程中从其中一两个模式开始,看看调试变得多容易.
处理错误并不光彩,但是它是一个系统之间的区别 一个快乐的维护,一个让你在晚上保持清醒。
选择能够使失败明显,清晰,易于追踪的图案.