商业智能和数据分析的应用在疫情期间发挥了重要作用

在其他函数式编程语言名字可能有所不同，但是意义相同。实际上，不仅仅是异常，正常的数据也会被包装到容器中，你需要通过容器的接口来获取数据。如果难以理解的话，你可以将其简单理解为 Promsie（但并不完全等价）。

Maybe 可能返回正常的数据 data，也可能会生成一个错误 error。某一个时刻只能是其中一个，并且只有运行的时候，我们才真正知道它是什么。从这一点来看，有点像薛定谔的猫

 

彻底消除运行时异常可能么？

我个人对目前前端现状最为头疼的一点是：大家过分依赖运行时，而严重忽略编译时。我见过很多程序，你如果不运行，根本不知道程序是怎么走的，每个变量的 shape 是什么。怪不得处处都可以看到 console.log。我相信你一定对此感同身受。也许你就是那个写出这种代码的人，也许你是给别人擦屁股的人。为什么会这样？ 就是因为大家太依赖运行时。TS 的出现很大程度上改善了这一点，前提是你用的是 typescript，而不是 anyscript。其实 eslint 以及 stylint 对此也有贡献，毕竟它们都是静态分析工具。

我强烈建议将异常保留在编译时，而不是运行时。不妨极端一点来看：假如所有的异常都在编译时发生，而一定不会在运行时发生。那么我们是不是就可以信心满满地对应用进行重构啦?

幸运的是，我们能够做到。只不过如果当前语言做不到的话，则需要对现有的语言体系进行改造。这种改造成本真的很大。不仅仅是 API，编程模型也发生了翻天覆地的变化，不然函数式也不会这么多年没有得到普及了。


 

本质上这只是一个语法糖，是 Promise.prototype.catch 的一个语法糖而已。而这一语法糖能够成立的原因在于其用了 Promise 这种包装类型。如果你不用包装类型，比如上面的 fs.readFile 不用 Promise 等包装类型包装，打死都不能用 try catch 捕获。

而如果我们使用 babel 转义下，会发现 try catch 不见了，变成了 switch case 语句。这就是 try catch “可以捕获异步异常”的原因，仅此而已，没有更多。


 

上面的代码会打印 catching an error。因为读取文件被同步发起，文件返回之前线程会被挂起，当线程恢复执行的时候， fs.readFileSync 仍然在函数调用栈中，因此 fs.readFileSync 产生的异常会冒泡到 catch 语句。

简单来说就是异步产生的错误不能用 try catch 捕获，而要使用回调捕获。

可能有人会问了，我见过用 try catch 捕获异步异常啊。 比如：


 

如上代码不会有任何异常被抛出，它被完全吞没了，这对我们调试问题简直是灾难。因此切记不要吞没你不能处理的异常。正确的做法应该是上面讲的那种只 catch 你可以处理的异常，而将你不能处理的异常 throw 出来，这就是责任链模式的典型应用。

这只是一个简单的例子，就足以绕半天。实际业务肯定比这个复杂多得多。因此异常处理绝对不是一件容易的事情。

如果说谁来处理是一件困难的事情，那么在异步中决定谁来处理异常就是难上加难，我们来看下。

同步与异步

同步异步一直是前端难以跨越的坎，对于异常处理也是一样。以 NodeJS 中用的比较多的读取文件 API 为例。它有两个版本，一个是异步，一个是同步。同步读取仅仅应该被用在没了这个文件无法进行下去的时候。比如读取一个配置文件。而不应该在比如浏览器中读取用户磁盘上的一个图片等，这样会造成主线程阻塞，导致浏览器卡死。

（编辑：盐城站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!