I’m working on learning Haskell, and I’ve come across three different ways of dealing with errors in functions I write:
- I can simply write
error "Some error message.", which throws an exception. - I can have my function return
Maybe SomeType, where I may or may not be able to return what I’d like to return. - I can have my function return
Either String SomeType, where I can return either an error message or what I was asked to return in the first place.
My question is: Which method of dealing with errors should I use, and why? Maybe I should different methods, depending on the context?
My current understanding is:
- It’s “difficult” to deal with exceptions in purely functional code, and in Haskell one wants to keep things as purely functional as possible.
- Returning
Maybe SomeTypeis the proper thing to do if the function will either fail or succeed (i.e., there aren’t different ways it can fail). - Returning
Either String SomeTypeis the proper thing to do if a function can fail in any one of various ways.
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 wayEither CustomType– I can fail, and I’ll tell you what happenedIO+ exceptions – I sometimes fail. Check my docs to see what I throw when I doerror– I hate you too user
3
I wouldn’t separate 2 and 3 based on how many ways something can fail. As soon as you think there’s only one possible way, another will show its face. The metric should instead be “do my callers care why something failed? Can they actually do anything about it?”.
Beyond that, it’s not immediately clear to me that Either String SomeType can produce an error condition. I would make a simple algebraic data type with the conditions with a more descriptive name.
Which you use depends on the nature of the problem you face, and the idioms of the software package you’re working with. Though I would tend to avoid #1.
3