Alright, first rule of error handling in Haskell: Never use
It's just terrible in every way. It exists purely as an act of history and the fact that Prelude uses it is terrible. Don't use it.
The only conceivable time you could use it is when something is so internally terrible that something must be wrong with the very fabric of reality, thus rendering the outcome of your program moot.
Now the question becomes
Maybe is nicely suited to something like
head, which may or may not return a value but there is only one possible reason to fail.
Nothing is saying something like "it broke, and you already know why". Some would say it indicates a partial function.
The most robust form of error handling is
Either + an error ADT.
For example in one of my hobby compilers, I have something like
data CompilerError = ParserError ParserError
| TCError TCError
| ImpossibleError String
data ParserError = ParserError (Int, Int) String
data TCError = CouldntUnify Ty Ty
| MissingDefinition Name
| InfiniteType Ty
type ErrorM m = ExceptT CompilerError m -- from MTL
Now I define a bunch of error types, nesting them so that I have one glorious top level error. This can be an error from any stage of compilation or an
ImpossibleError, which signifies a compiler bug.
Each of these error types try to keep as much information for as long as possible for pretty printing or other analysis. More importantly, by not having a string I can test that running an illtyped program through the type checker actually generates a unification error! Once something is a
String, it's gone forever and any information it contained is opaque to the compiler/tests, so just
Either String isn't great either.
Finally I pack this type into
ExceptT, a new monad transformer from MTL. This is essentially
EitherT and comes with a nice batch of functions for throwing and catching errors in a pure, pleasant way.
Finally, it's worth mentioning that Haskell has the mechanisms to support handling exceptions like other languages do, except that catching an exception lives in
IO. I know some people like to use these for
IO heavy applications where everything could potentially fail, but so infrequently that they don't like to think about it. Whether you use these impure exceptions or just
ExceptT Error IO is really a matter of taste. Personally I opt for
ExceptT because I like being reminded of the chance of failure.
As a summary,
Maybe - I can fail in one obvious way
Either CustomType - I can fail, and I'll tell you what happened
IO + exceptions - I sometimes fail. Check my docs to see what I throw when I do
error - I hate you too user