3 ms·

1. Your assumption is wrong, I definitely didn't mean panic. 2. I think the arrow means assignment in Haskell and you are just referring to monadic errors? To

1. Your assumption is wrong, I definitely didn't mean panic. 2. I think the arrow means assignment in Haskell and you are just referring to monadic errors? To use them the same way proper error handling is done in Go, you would just have more nesting and multiple unwraps, which is marginally different than Go syntax (but definitely with more compiler checking.) The arrow syntax in Go is used by channels.

mrkgnao 9y ago
Apologies. In any case, monadic errors in Haskell allow you to make "failing early" automatic. Even a simple use of optional types can make a difference. For instance, here you're failing with the same error every time, like here: a, err := squareRoot(x) if err { handle(err) } b, err := log(a) if err { handle(err) } c, err := log(b) if err { handle(err) } you can just use an optional ("Maybe") type: write a, b, and c with types like a :: Double -> Maybe Double and then do a <- squareRoot x b <- log a c <- log b If the computation of a fails, the whole computation fails. The compiler takes care of all the error-checking plumbing. I think the ergonomics of this common kind of situation are really suboptimal in Go, which to my knowledge doesn't support anything remotely similar.
- dullgiulio 9y ago
  That's right. But I prefer to decorate each error as it comes back from the callee, writing what I was trying to do that failed. This gives a human readable trace of the problem, and also a unique signature for the error itself.
  - masklinn 9y ago
    > But I prefer to decorate each error as it comes back from the callee That's trivially feasible and still shorter than the Go version: a <- decorate (squareRoot x) b <- decorate (log a) c <- decorate (log b) Outside of the do context, your return value is just that, a value, you can manipulate it using the language's regular tooling. And you can decorate the do context itself if you want the same decoration for all calls in the block.

mrkgnao 9y ago

Apologies. In any case, monadic errors in Haskell allow you to make "failing early" automatic. Even a simple use of optional types can make a difference. For instance, here you're failing with the same error every time, like here: a, err := squareRoot(x) if err { handle(err) } b, err := log(a) if err { handle(err) } c, err := log(b) if err { handle(err) } you can just use an optional ("Maybe") type: write a, b, and c with types like a :: Double -> Maybe Double and then do a <- squareRoot x b <- log a c <- log b If the computation of a fails, the whole computation fails. The compiler takes care of all the error-checking plumbing. I think the ergonomics of this common kind of situation are really suboptimal in Go, which to my knowledge doesn't support anything remotely similar.

dullgiulio 9y ago
That's right. But I prefer to decorate each error as it comes back from the callee, writing what I was trying to do that failed. This gives a human readable trace of the problem, and also a unique signature for the error itself.
- masklinn 9y ago
  > But I prefer to decorate each error as it comes back from the callee That's trivially feasible and still shorter than the Go version: a <- decorate (squareRoot x) b <- decorate (log a) c <- decorate (log b) Outside of the do context, your return value is just that, a value, you can manipulate it using the language's regular tooling. And you can decorate the do context itself if you want the same decoration for all calls in the block.