This page discusses the not-yet-released control-monad-failure package and its associated packages. As of this writing (November 7, 2009), the packages are expected to be released within the next week.

Exceptions, errors, failures oh my!

Terminology is a little confusing. There's a few different things floating around:

Error usually refers to a programming error. It can also refer to the "error" function, which in fact causes a runtime exception to be triggered.
Exception usually refers to an exception which is thrown in the IO monad. It can also refer to the actually typeclass "Exception" which was introduced along with extensible exceptions.
Fail is referring to the "fail" function, which is part of the Monad typeclass and is almost universally despised.

To avoid the baggage and name clashes introduced with all of the above, we use the term failure. This name is used consistently for module names, type classes, function names and the abstract concept.

But what is a failure? It's any time that something does not succeed. Of course, this depends on your definition of success. Here are some examples:

readInt fails when it receives invalid input.
head fails when it receives an empty list.
lookup fails when the key is not find in the list.
at (also known as !!) fails when the index is past the end of the list.

Now that we know what a failure is, let's discuss how to deal with it.

Prior Art

There are currently a number of methods available for dealing with failures. However, all of them are lacking in some way:

Maybe. However, there's no information on *what* failed.
The error function. But not all failures should be fatal.
IO exceptions. But they force your code into your IO monad, plus it's non-obvious that a function might fail with an exception based solely on its return type.
Custom error values. But how do you compose two libraries together?
The Either/ErrorT monads. Apart from the fact that Either is not a Monad by default (you can use the mtl or transformers instances, but that introduces undesirable orphan instances), the main problem with these lies in composability and extensibility.

This abundance of error handling methods leads to lots of gluing code when combining libraries which use different notions of failure. Examples:

The partial functions in the Prelude and other base modules, such as head, tail, fromJust, lookup, etc. use the error function.
parsec models failure using Either ParseError
http models failure using Either ConnError
The HDBC package models failure using the SQLError exception
The cgi package uses exceptions

Quoting from Eric Kidd:

Consider a program to download a web page and parse it:

1. Network.URI.parseURI returns (Maybe URI).
2. Network.HTTP.simpleHTTP returns (IO (Result Request)), which is basically a broken version of (IO (Either ConnError Request)).
3. Parsec returns (Either ParseError a)

So there's no hope that I can write anything like:

  do uri <- parseURI uriStr
     doc <- evenSimplerHTTP uri
     parsed <- parse grammar uriStr doc

Enter control-monad-failure, stage left

What we want is an abstract notion of failure which does not tie us to any particular error handling mechanism. This is what the control-monad-failure package intents to provide.

MonadFailure is the typeclass used to model this abstract notion of failure. It lives in the Control.Monad.Failure module and consists entirely of the following two lines:

   class Monad m => MonadFailure e m where
       failure :: e -> m a

So now, you could define a safe head function as follows:

   data EmptyListFailure = EmptyListFailure
   head :: MonadFailure EmptyListFailure m => [a] -> m a
   head [] = failure EmptyListFailure
   head (x:_) = return x

Notice how the opposite of failure is "return".

Handling failures

Each of the mentioned error handling mechanisms is equipped with a primitive for handling a failure. When dealing with a failure, it's obvious based on the type signature what might go wrong. In the example of head above, obviously head will fail if the list is empty.

In any event, we need to instantiate MonadFailure in order to actually call the head function. The control-monad-failure package comes with instances for each of the mentioned error handling mechanisms.

Maybe. failure == Nothing
List. failure == []
IO. failure == throw
Either. failure == Left
ErrorT (provided by mtl or transformers). failure == throwError.

However, there are also two other packages available which provide more resilient options.

control-monad-exception

c-m-e provides a EM monad for explicitly typed, checked exceptions a la Java. The type of a EM computation carries the list of exceptions it can throw in its type. For example, let's say that we have a basic arithmetic expression evaluator which can throw divide by zero or sum overflow exceptions. Its type will be:

   eval :: (Throws DivByZero l, Throws SumOverflow l) => Expr -> EM l Double

Correspondingly, a computation which calls eval and handles only the DivByZero exception gets the type:

   :t eval <expr> `catch` \DivByZero -> return 0
     eval <expr> :: Throws SumOverflow l => EM l Double

attempt

Attempt is intended when you don't know what might go wrong, but you know it could happen. For example, let's say I want to define a type class:

   class Convert a b where
       convert :: a -> Attempt b

Other libraries may want to instantiate Convert for their own types. However, when writing the Convert typeclass, I don't know exactly what failures may occur. When writing the "Convert String Int" instances, it might be InvalidInteger. But when writing the "Convert English Spanish" typeclass (hey, it could happen) it might be InvalidGrammar.

safe-failure

safe-failure is a collection of functions which return values in the MonadFailure monad. It provides all the functions available in Neil Mitchell's safe package, plus a few extra.

Stack traces

As an added bonus, both control-monad-exception and attempt support MonadLoc, meaning you can get stack traces. More information available in Jose's blog post [1].

Failure

Contents