Stream: API design

Topic: should we have Task.attempt in addition to Task.onErr?


view this post on Zulip 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?

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip 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: Jul 06 2025 at 12:14 UTC