我的活动在执行期间会不时抛出异常,因此我实现了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方法中流出来,以便行为能够正确处理它。