The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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.
Either String. Two problems here: 1) Either is not a Monad by default. You can use the mtl or transformers instances, but that introduces orphan instances and all the associated issues. 2) A String is a bit limiting sometimes.
The error function. But not all failures should be fatal.
Runtime exceptions. You need to be in IO to handle it, plus it's non-obvious that an exception might have been thrown based on return type.
Custom error values. But how do you compose two libraries together?

Enter control-monad-failure, stage left

What we want is a mechanism for failure which is flexible enough to provide all the information we might want. That happens to be provided very nicely by extensible exceptions. control-monad-failure is simply a mechanism for using extensible exceptions outside of the IO monad while explicitly stating the possibility of failure.

MonadFailure is the typeclass used to glue everything else together. It lives in the Control.Monad.Failure module in the control-monad-failure package (fancy that), 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".

Catching failures

Catching isn't really the right term at all. When you catch an exception in the IO monad, it's sort of like fishing in the dark abyss which is the impurity of the real world. 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 won't succeed if the list is empty.

In any event, we need some instances of MonadFailure in order to actually call the head function. There are some built in with the control-monad-failure package. However, there are also two other packages available which provide more resilient options. The built in offerings are:

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

However, each of these runs into the issues described previously.

control-monad-exception

The c-m-e library allows you to cleanly define which failures might occur in a function, and to handle failures one at a time.

FIXME: Jose, this could use a better description (clearly).

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