Feedback for “Expected Errors”

[RoryO]

Regarding collections and fail fast, I've run into this a few times now and I don't think there's an answer for this anywhere. What do you do if you have a collection of something, each member results in a computation with an Effect that may fail, and you don't want to halt? You want to run the entire collection regardless if an individual one fails or not. With fp-ts this would be like traversing a collection of TaskEither with ApplicativeSeq, which will map A[] => Either<E, B>[]. It doesn't seem like this is an unusual situation.

If we take the example of sending a collection of emails from elsewhere in the documentation, you don't want to halt the entire process because one email in the middle of the collection bounced for some reason. It is an error, but not one that should shut down the entire flow right away. We want to know that after the fact.

I think the answer is first run though the collection producing Effect<R, E, A = Either<EB, B>[]>, and then transform the EB on A into E when done. However, Michael on Discord mentioned that the E in an Effect should be singular.

Put another way how should we model the types and write the procedure where we do not want to fail at the first error in a collection, but we do want to collect the errors after the sequence?

[nspaeth]

Maybe you're looking for validateAll ?

[RoryO]

No, because I want both sets of information. Say I want a collection A[] => Effect<R, E[], B[]>, and then I want to further process B[] => Effect<R, EE[], C[]>, then zip E[] and EE[] so the result is Effect<R, E[] | EE[], C[]>. validateAll unfortunately makes B never if there are any E. A version of validateAll that does not set B to never would be perfect.

Note that this function is lossy, which means that if there are any errors, all successes will be lost. If you need a function that preserves both successes and failures, please refer to the partition function.

I am actually using partition and Effect.either, in my current processes. It's just rather unwieldy.