我知道监督者可以监控许多进程，OTP监督者提供了很好的默认值，比如如果X时间内有太多错误，那么就不要重试。
我的问题是，你个人什么时候选择try-catch而不是进程监视器。
您所说的工具有两个完全不同的用例。
你应该只在一个需要与其他事情并行发生的过程中运行一些事情。因此，我认为，当您在等待结果（即顺序程序）时需要捕获错误时，应该使用try/catch。当你需要并行运行某个程序时，你应该使用一个外部程序，如果你对该程序中发生的异常感兴趣，你应该监控它。
话虽如此，当然也有一些边缘情况下，将活动外部化到流程中是有意义的，比如特殊的垃圾收集角落情况（有时通过杀死流程来垃圾收集活动更容易/更快）。
就性能而言，涉及的参数太多了（try/catch与monitor的开销、代码运行的频率等），您必须为您的案例进行基准测试。
我更喜欢只在抛出错误是正常行为的情况下使用try/catch，例如grpoc中的lookup_value/1（如果密钥没有注册，它会抛出badarg，而我希望并更喜欢得到undefined）。
这就是我所理解的Erlang哲学：你应该为好的案例进行编程，而不是试图过多地防御，即在某些情况下你应该关心，而在大多数情况下只是让它崩溃。