Yes, Result is worth looking at. It's like Maybe, except the error case can carry some information too (usually a string). Task is used for asynchronous effects (e.g. HTTP requests) which often can fail in odd ways. I'd focus on Result for now, as all the tooling I'm about to mention is the same across these types.
Joey mentioned we like to map over arrays. Well, you can also map over a Maybe or a Result. The trick is that these are also data structures; they just happen to hold at most one (successful) element. So you find yourself doing things like String.parseInt "not an integer" |> Result.map doSomethingWithTheInt |> Result.andThen doSomethingWithTheIntThatCouldFail This way you build up pipelines that ignore the fact that you don't actually have an integer. The error short-circuits the pipeline and gets handled at the end, so it's like throwing in that you can handle the error at a distance. And you can collapse many errors into one case that you handle all in one place. (minor detail: this is using the argument order for andThen coming in 0.18) I few weeks ago I had to add a lot of try...catch blocks around someone else's code, and let me tell you, it wasn't fun. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
