从行业中来，到行业中去

上面的 resume 是我定义的一个关键字，功能是如果遇到异常，则返回到异常发生的地方，然后给当前发生异常的函数一个返回值 -1，并使得后续代码能够正常运行，不受影响。这其实是一种 fallback。

这绝对是一个超前的理念。当然挑战也非常大，对现有的体系冲击很大，很多东西都要改。我希望社区可以考虑把这个东西加到标准。

最佳实践

通过前面的学习，你已经知道了异常是什么，异常是怎么产生的，以及如何正确处理异常（同步和异步）。接下来，我们谈一下异常处理的最佳实践。

我们平时开发一个应用。 如果站在生产者和消费者的角度来看的话。当我们使用别人封装的框架，库，模块，甚至是函数的时候，我们就是消费者。而当我们写的东西被他人使用的时候，我们就是生产者。

实际上，就算是生产者内部也会有多个模块构成，多个模块之间也会有生产者和消费者的再次身份转化。不过为了简单起见，本文不考虑这种关系。这里的生产者指的就是给他人使用的功能，是纯粹的生产者。

从这个角度出发，来看下异常处理的最佳实践。

作为消费者

当作为消费者的时候，我们关心的是使用的功能是否会抛出异常，如果是，他们有哪些异常。比如：



 

如果我想让它打印呢？我想让程序面对异常可以自己 recover 怎么办？我已经捕获这个错误， 并且我确信我可以处理，让流程继续走下去吧！如果有能力做到这个，这个就是运行时异常恢复。

遗憾地告诉你，据我所知，目前没有任何一个引擎能够做到这一点。

这个例子过于简单， 只能帮助我们理解什么是运行时异常恢复，但是不足以让我们看出这有什么用？


 

elm 也不会发生。原因也很简单，因为 null 也会被包装起来，当你通过这个包装类型就行访问的时候，容器有能力避免这种情况，因此就可以不会发生异常。当然这里有一个很重要的前提就是可推导，而这正是函数式编程语言的特性。这部分内容超出了本文的讨论范围，不再这里说了。

运行时异常可以恢复么？

最后要讨论的一个主题是运行时异常是否可以恢复。先来解释一下，什么是运行时异常的恢复。 还是用上面的例子：

（编辑：盐城站长网）

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