I'm working on learning Haskell, and I've come across three different ways of dealing with errors in functions I write:

  1. I can simply write error "Some error message.", which throws an exception.
  2. I can have my function return Maybe SomeType, where I may or may not be able to return what I'd like to return.
  3. 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 SomeType is 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 SomeType is the proper thing to do if a function can fail in any one of various ways.

2 Answers 2


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
  • This answer clears up a lot for me. I was second-guessing myself based upon the fact that built-in functions like head or last seem to use error, so I was wondering if that was actually a good way to do things and I was just missing something. This answers that question. :)
    – CmdrMoozy
    Aug 11, 2014 at 19:58
  • 5
    @CmdrMoozy Glad to help :) It's really unfortunate that prelude has such bad practices. Such is the way of legacy :/ Aug 11, 2014 at 19:59
  • 3
    +1 Your summary is amazing Nov 8, 2014 at 17:25

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.

  • Actually, using Either for errors is a very well-known pattern in Haskell.
    – Rufflewind
    Aug 12, 2014 at 2:03
  • 1
    @rufflewind - Either isn't the unclear part, the use of String as an error rather than an actual string.
    – Telastyn
    Aug 12, 2014 at 3:03
  • Ah, I misread your intent.
    – Rufflewind
    Aug 12, 2014 at 3:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.