我的活动在执行期间会不时抛出异常，因此我实现了Activity<TInstance>的Faulted方法来处理该问题，并丢弃了Execute方法中所做的更改。我以为“自动名称”下面有一些连接，使得Execute方法引发异常时执行Faulted方法，然后为已执行的活动调用Faulted方法。事实证明，没有这样的事情，因为我的Faulted方法从未执行过。
我应该在try / catch块中给自己打电话吗？我可以基于BehaviorExceptionContextProxy生成BehaviorContext并抛出异常。我唯一可以通过的下一个Behavior是插入该Activity的{{1}}方法中的那个，但是从逻辑上讲，这意味着我在错误的方向上进行了补偿，因为下一个{{1 }}实际上是在此操作成功后执行的，所以我要补偿太多。
我还尝试在状态机中使用Execute，它确实处理了异常，但是，我找不到任何方法来为仅在失败的活动中启动补偿流程执行出现Behavior。
有什么好的方法可以触发活动的补偿流吗？
答案 0 :(得分：1)
状态机中的活动（使用自动机）与Courier中的活动有很大不同。不幸的是，它们的名称相同，可能会造成混淆。
当活动引发异常时，将调用行为中下一个活动的Faulted方法。如果该方法是常规活动方法（例如.Then，.Publish等），则将其跳过，因为这些活动的Faulted方法只会调用行为中的下一个活动。
但是，Catch活动可用于捕获异常并执行救援行为（这是一系列活动）。
无论哪种方式，都不会调用在Execute方法内引发异常的活动的Faulted方法。所以是的，您应该使用try / catch，但是允许异常从Execute方法中流出来，以便行为能够正确处理它。