scala – Future何时能够返回一个不会从Future体内抛出的异常？
|
这里更一般的问题是：在生产质量代码中,是否需要关注ExecutionContext或其他并发基础结构产生的异常,而不是未来主体的执行？例如,如果线程池发生某些故障,我会在未来看到因为它而无法执行的异常吗？
反过来,这导致了如何使用期货进行错误处理.我正在使用一般建议,即应该使用例如错误返回错误,而不是抛出错误.无论是要么是scalactic的,要么是.但是,如果在调用未来时,需要考虑基础结构中的异常,即使其他所有内容都以无异常或异常包装的方式编写,这似乎也非常复杂.但我不会就此提出建议 – 我认为这个帖子会因为“过于宽泛”而被关闭. ：=( 解决方法
是和否……好吧也许我们需要详细说明.
如果我们谈论“生产质量代码”,即如果它不起作用则需要花费大量资金的代码,我们不能假设基础设施(运行时,库等)正常工作.因为他们没有.库有错误,即使它们不影响我们,它们依赖于有限的资源,如内存,文件句柄和并发的东西：线程. 因此,在某种程度上应该意识到的一件事是：即使是最微不足道的代码行也可能会失败.这就是Yes部分：是的,你应该关注这种可能性. No部分旁边：你写的
对于您期望的异常,这是正确的.事情真的很可能会失败.比如在10万次执行中超过1次. (是的,我把那个号码从我的帽子里拿出来,我甚至都不戴).在这种情况下,添加显式异常处理是适当的事情,并且您提到的建议适用. 但它并不适用于所有其他可能的故障模式.如果您尝试使用此方法处理它们,您将无法在所有异常处理之间找到主代码.你可能会在这个过程中添加许多错误. 相反,有一些一般策略如何处理代码中的任意异常.对于这些情况,例外是正确的工具.对于这种策略越简单越好,因为你真的不知道在什么样的情况下这个代码会被执行. Web应用程序中的典型方法是在完整请求周围尝试catch块,记录异常并返回一些错误页面. 一个更精细的方法是像Akka这样的演员框架,它有Actors来完成工作.如果这样的Actor抛出异常,则Actor将死亡并被新的替换(用各种方式来控制确切的行为). 另一种与上述两种方法相结合的方法是让应用程序的多个实例在不同的机器上运行,因此一台机器上的问题不会影响其他机器. 正如您所看到的,处理基础结构内部异常的方法(包括但不限于执行期货的库)与用于处理期货“正常”故障模式的异常处理非常不同. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |