You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All CompletionStage* strategies currently have duplicated exception handling, both for synchronous case and asynchronous case. They typically look similar to:
This is just the core, all the strategies do metric updates, internal state updates, strategy-specific logic, etc. This all has to be duplicated between <1> and <2>.
It would be much better if we could just rely on asynchronous exception handling. The only place exceptions can be thrown synchronously from is (or should be) the ultimate end-user method call (i.e., the Invocation strategy). We can wrap it into another strategy that will make sure exceptions are not propagated synchronously. Implementation of such strategy is actually the exact code given above (but we'd use CompletionStages.propagateCompletion instead). All the other CompletionStage* strategies then don't have to care about synchronous exceptions and can drop the try/catch structure.
The text was updated successfully, but these errors were encountered:
At this point, I'm not exactly sure we should do this. The synchronous exception handling at least guards against mistakes in our own code -- which are really easy to make, because exceptions can be thrown from anywhere. I'll keep this issue open for now, because the duplication isn't nice and there might be something else we could do.
All
CompletionStage*
strategies currently have duplicated exception handling, both for synchronous case and asynchronous case. They typically look similar to:This is just the core, all the strategies do metric updates, internal state updates, strategy-specific logic, etc. This all has to be duplicated between
<1>
and<2>
.It would be much better if we could just rely on asynchronous exception handling. The only place exceptions can be thrown synchronously from is (or should be) the ultimate end-user method call (i.e., the
Invocation
strategy). We can wrap it into another strategy that will make sure exceptions are not propagated synchronously. Implementation of such strategy is actually the exact code given above (but we'd useCompletionStages.propagateCompletion
instead). All the otherCompletionStage*
strategies then don't have to care about synchronous exceptions and can drop thetry
/catch
structure.The text was updated successfully, but these errors were encountered: