Failure

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 actual 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 found 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. 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 failure package, 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 failure package intends to provide.

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

   class Failure e f where
       failure :: e -> f v

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

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

Notice how the opposite of failure is "return". Here, we introduced the Monad requirement explicitly; there are also two convenience classes that can help you out here:

• ApplicativeFailure. In this case, just replace "return" with "pure"
• MonadFailure: code would remain exactly as-is.

Handling failures

When dealing with a failure, the type signature states what might go wrong. In the example of head above, head will fail if the list is empty.

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

• Maybe. failure == Nothing
• List. failure == []
• IO. failure == throw
• Either. failure == Left

Note: we previously provided an instance for ErrorT, where failure == throwError. Now, however, this is provided by the control-monad-failure or control-monad-failure-mtl packages.

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.

Stack traces

As an added bonus, control-monad-exception provides stack traces, or more exactly monadic call traces, via MonadLoc.

See also

• Error
• Exception
• Error vs. Exception

References

• http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-errors
• http://www.haskell.org/pipermail/libraries/2007-March/007010.html