Alright, first rule of error handling in Haskell: Never use error
.
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
vs Either
. 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