Monix Task integration: taskAttempt behaves differently from Task.attempt

[benhutchison]

Test case at: benhutchison@48168df#diff-cff438ec1f43164ec2aa67018334de6bR175

[benhutchison]

This evaluation throws an exception:

taskDelay[Fx.fx1[Task], Unit](()).map(_ => throw new Exception()).taskAttempt.runAsync.runSyncUnsafe(1.seconds)

While this one traps its and returns a left Either:

taskDelay[Fx.fx1[Task], Unit](()).map(_ => throw new Exception()).runAsync.attempt.runSyncUnsafe(1.seconds)

The difference is the first uses taskAttempt Eff-combinator, while the second uses underlying monix operation on the final task.

Problem is that there are some situations where this isn't a desirable change to make in program. When using Writer for logging, I think it is better to interpret Writer after Errors, to end up with:

val (result, logs) = program.taskAttempt.runWriter.runAsync.runSyncUnsafe(1.seconds)

But if the attempt must be done at the end, on Task, then you'll only get logs for a successful run, and its often during errors the logs are most useful.

[benhutchison]

I think I understand why this happens. taskAttempt appends an attempt call onto every existing task in the Eff expression. But the map call doesnt wrap the exception in a task, and so (only) if it comes at the end of the chain, it'll come after the last attempt.

The workaround is to wrap anything that could throw in a taskDelay, which is a fair ask if you're using Task as an IO type.