我想交叉张贴一个问题，我原来posted on Akka's user forum。
- 在 akka 键入 *：允许受监督的接收行为返回新的受监督的接收行为的动机是什么？
假设我们有一个接收行为R1，由一个监督者S1修饰。作为消息处理的一部分，R1返回一个新的接收行为R2，它本身由管理程序S2修饰。
akka 允许这样做。为什么？我在网上找不到类似的例子。这是不寻常的：通常，主管装饰一次行为。因此，我试图提出一些激励的例子，我正在寻找验证。
场景一：
- R1可以在消息处理过程中抛出Exception1（且仅限Exception1）。S1修饰R1处理Exception1。
- R1返回R2。假设R2可以抛出Exception2作为消息处理逻辑的一部分。S1仍然存在，但它只处理Exception1，而不是Exception2。因此，我们必须用处理Exception2的S2来修饰R2。
这有意义吗？如果是的话，为什么不让S1通过嵌套调用onFailure直接处理Exception1和Exception2呢？
场景二：
- R1可以在消息处理过程中抛出Exception1和Exception2。S1通过使用重启策略嵌套调用onFailure来处理这两个故障。
- R1返回R2。假设我们想要覆盖S1对Exception2的监督策略：重新开始而不是重新启动。为了做到这一点，我们用S2处理带有恢复策略的Exception2来装饰R2。
正如在Akka的用户论坛帖子中所讨论的那样，监督员的评估顺序是从内到外。因此，S2对Exception2的监督策略将覆盖S1的策略。
常见问题
我走对了吗？这种情景在真实的生活中出现过吗？
1条答案
按热度按时间z9gpfhce1#
Akka类型化设计的这一部分是我最不确定的，关于如何做到这一点有几次迭代。
从我的观点来看，最终的结果是行为不应该包括监督，因为父行为者有责任决定处理哪些失败，以及升级哪些失败（阻止子行为者，可能导致父行为者失败）。
这种区别 在Java/Scala类型系统中并不能很好地表现出来--如果行为可以被可选地监督，那么任何人都可以这样做 。唯一的递归是要求
spawn()的SupervisedBehaviour，强制将一个监督方案添加到原始Behaviour。这感觉也不对，因为它限制了选择代码模块化的自由。简而言之，虽然场景1听起来似乎很合理，但它并没有得到真正的完美支持，因为稍后去掉S2需要相当多的丑陋样板代码。