What's your approach to CancellationError handling?

[gilgtm]

TCA seems to be of a dual mind when it comes to swallowing CancellationError. Wrap your operation in a TaskResult and then you have to handle the CancellationError in the received action. Alternatively, pass a throwing operation into Effect.run and it will automatically swallow your CancellationError.

What's the reason for these differences in cancellation handling and how do you decide between these two approaches?

[stephencelis]

@gilgtm Having TaskResult rethrow cancellation errors was actually pitched and implemented here:

#1934

But after some thought, it made less sense for TaskResult to ignore cancellation, since it's more similar to the Result type and do-catch, and so you probably do want to handle cancellation to clean up your state.

[gilgtm]

Thanks, that makes sense! I'm still wondering when do you use one approach or the other?

Copying @stephencelis's answer to my follow-up from slack so I don't lose it:

TaskResult is mainly a Result that is TCA-friendly, since Error is not equatable, so it behaves in async contexts the same way Result.init(catching:) behaves in non-async contexts
Whereas Effect.run introduces async contexts, where we have made the decision to swallow cancellation errors for ergonomic purposes
If you are dealing with a long async task that may fail or be cancelled, and you need to clean up state afterwards, you can use do-catch or a TaskResult
If cancellation doesn't have an impact on state, you can use Effect.run normally