Richard Feldman (Jan 02 2024 at 19:53): Richard Feldman (Jan 02 2024 at 19:53):I've been noticing that it basically always seems nicer to use Task.onErr to handle errors than Task.attempt - any reason we should keep both, given you can always build your own Task.attemptin userspace with |> Task.map Ok |> Task.onErr Err |> Task.await?
Isaac Van Doren (Jan 02 2024 at 20:02):I think having both await and attempt is a bit confusing so I’m in favor of removing attempt
Luke Boswell (Jan 02 2024 at 20:40):I find I prefer Task.attempt sometimes, I use it frequently. On my mobile rn but I can dig out some examples of where I like to use it.
Anton (Jan 03 2024 at 08:52):The examples repo has three examples that use attempt. Rewriting those to use onErr and seeing how that looks seems like a good idea. onErr seems much easier to understand and remember so it would be nice to cut attempt.
Brendan Hansknecht (Jan 03 2024 at 15:51):Attempt enables you to use a task as a result. I think it is better unless you strictly are able to merge and pipeline all errors (or if you just need a result for something). So I find it useful.
Last updated: Nov 28 2025 at 12:16 UTC