何时将@Suspendable添加到流中的方法？

Question

将方法注释为@Suspendable的最佳实践是什么？在流中，可能有多个私有方法查询Vault /计算业务逻辑。是否应使用@Suspendable进行注释，以便在节点崩溃时可以恢复？

或者@Suspendable仅用于其中send / sendAndReceived涉及等待对手方响应的方法吗？

Answer 1

来自paralleluniverse：

  

Fiber，SuspendableRunnable和SuspendableCallable中的运行方法   声明他们可能会抛出SuspendExecution异常。

     @Suspendable是我们通过声明throws SuspendExecution来指定可挂起方法的方法，这很方便，因为SuspendExecution是一个已检查的异常，因此如果f调用g并且g是可挂起的，则Java编译器将强制我们声明f为可挂起的（必须是因为它调用g，并且g可能被挂起了）。

     

但是，有时我们不能声明f抛出SuspendExecution。一个例子是f是接口方法的实现，我们不能（或不想）更改接口以使其抛出SuspendExecution。

     

因此，假设方法f在接口I中声明，那么我们希望使其在C类中的实现可挂起。编译器不会让我们声明我们抛出SuspendExecution，因为这将与f在I中的声明冲突。

     

然后，我们要做的是使用@Suspendable注释（在co.paralleluniverse.fibers包中）对C.f进行注释。假设C.f调用了park或其他可挂起的方法g（确实声明抛出SuspendExecution），我们需要用try {} catch（SuspendExecution）包围f的主体，以便该方法可以编译。

     

如果我们要在光纤中运行h，则它必须是可挂起的，因为它调用f是可挂起的。我们可以通过用@Suspendable注释h或通过声明SuspendExecution来指定h为可挂起

如果我们希望任何方法都可以在光纤中运行，那么它必须是可挂起的。 因此，基本上，任何调用可以抛出SuspendExecution或带有@Suspendable注释的方法的方法。

在我的情况下，我遇到了从函数调用SubFlow的错误，因为我没有用@Suspendable对其进行注释，所以我遇到了类星体异常。在SubFlow和@Suspendable一起注释的同时，我的函数也帮助摆脱了这些错误。 错误：Uninstrumented whole methods ('**') or single calls ('!!') detected: