3 ms·
Yeah, if you need to explicitly do something with the error then you fall back to a matcher. But the idea is that you only need to deal with errors at error bou
by thinkharderdev 5y ago
Yeah, if you need to explicitly do something with the error then you fall back to a matcher. But the idea is that you only need to deal with errors at error boundaries which you can define. So if you just want to pass an error up the stack to be handled somewhere else then you can with almost no syntactic overhead.
With something like a functional effect system you can even do better than that. For instance with Scala ZIO you can do something like:
```
val result = for {
fooResult <- foo().tapError(e => console.putStrLn(s"Error in foo!: $e")
barResult <- bar(fooResult).tapError(e => console.putStrLn(s"Error in bar!: $e")
bazResult <- baz(barResult)
} yield bazResult
```
Then when you run the bazResult effect you get either an error or the result type which you can handle however you like.