在什么情况下你会使用进程监视器而不是函数的try catch

Question

我知道主管可以监控许多进程，而OTP主管提供了很好的默认设置，比如X时间内有太多错误，那么就不要重试了。

我的问题是，您何时亲自选择尝试捕获进程监视器。

Answer 1

您所说的工具有两个完全不同的用例。

您应该只在一个需要与其他东西同时发生的过程中运行。因此，我认为当你需要在等待结果的情况下（即顺序程序）捕获错误时，你应该使用try / catch。当你需要并行运行某些东西时，你应该使用一个外部进程，如果你对该进程中发生的异常感兴趣，你应该监视它。

话虽如此，当然还有边缘情况，将活动外部化到流程中是有道理的，例如特殊的垃圾收集角落案例（有时通过杀死其流程来垃圾收集活动更容易/更快）

性能方面，涉及的参数太多（try / catch与监视器的开销，代码运行的频率等），您必须根据自己的情况进行基准测试。

Answer 2

我更喜欢在抛出错误是正常行为的情况下使用try / catch。比如，lookup_value/1 grpoc {如果密钥未注册则会抛出badarg，而我期望并希望改为undefined。

我理解的那个Erlang哲学：你应该为好的案例编程，而不是试图过于防守，即在某些情况下你应该关心，而在大多数情况下只是让它崩溃。