3 ms·
It doesn't. You can use an inclusive sum type (i.e. inclusive or), which would be success, error, or result with accompanying error. You can think of it as succ
by dwohnitmok 8y ago
It doesn't. You can use an inclusive sum type (i.e. inclusive or), which would be success, error, or result with accompanying error. You can think of it as success, fatal error, or non-fatal error.
The same machinery still works and it's pretty straightforward to convert between the two representations (so you can track which parts of your code bail out at the first error and which parts try to soldier on).
See for example http://hackage.haskell.org/package/these http://hackage.haskell.org/package/these or https://typelevel.org/cats/datatypes/ior.html https://typelevel.org/cats/datatypes/ior.html or https://github.com/purescript-contrib/purescript-these https://github.com/purescript-contrib/purescript-these
For a lot of FP languages that take this approach to errors you'll have three representations (bail out at first error, continue on nonfatal errors, and bail on any error but first try to accumulate as many errors as possible as a batch) that all have conversions between them depending on what you want the semantics of that section of your code to be.
- merb 8y agobtw haskell also has a concept of exception, so it's not like that you need These or Either for all cases, in some cases using a exception might be good enough.
- dwohnitmok 8y agoExceptions do exist but their usage in Haskell is mainly restricted to code living in IO (as a result of both community customs and the restriction of handlers to IO code). FWIW personally I think of exceptions in Haskell almost exclusively as a tool for thread management and tend to shy away from using it for only error handling (although the two do have some overlap). But that's a more divisive topic in the Haskell community at large than the ban on exceptions in pure code.