| Haskell Hierarchical Libraries (base package) | Contents | Index

Control.Exception

Portability | non-portable
Stability | experimental
Maintainer | libraries@haskell.org

Contents

The Exception type
Throwing exceptions
Catching Exceptions
  The `catch` functions
  The `handle` functions
  The `try` functions
  The `evaluate` function
  The `mapException` function
  Exception predicates
Dynamic exceptions
Asynchronous Exceptions
  Asynchronous exception control
    Applying `block` to an exception handler
    Interruptible operations
Assertions
Utilities

Description
This module provides support for raising and catching both built-in and user-defined exceptions.
Synopsis

data Exception

= ArithException ArithException
| ArrayException ArrayException
| AssertionFailed String
| AsyncException AsyncException
| BlockedOnDeadMVar
| Deadlock
| DynException Dynamic
| ErrorCall String
| ExitException ExitCode
| IOException IOException
| NoMethodError String
| NonTermination
| PatternMatchFail String
| RecConError String
| RecSelError String
| RecUpdError String

data IOException

data ArithException

= Overflow
| Underflow
| LossOfPrecision
| DivideByZero
| Denormal

data ArrayException

= IndexOutOfBounds String
| UndefinedElement String

data AsyncException

= StackOverflow
| HeapOverflow
| ThreadKilled

throwIO :: Exception -> IO a
throw :: Exception -> a
ioError :: IOError -> IO a
throwTo :: ThreadId -> Exception -> IO ()
catch :: IO a -> (Exception -> IO a) -> IO a
catchJust :: (Exception -> Maybe b) -> IO a -> (b -> IO a) -> IO a
handle :: (Exception -> IO a) -> IO a -> IO a
handleJust :: (Exception -> Maybe b) -> (b -> IO a) -> IO a -> IO a
try :: IO a -> IO (Either Exception a)
tryJust :: (Exception -> Maybe b) -> IO a -> IO (Either b a)
evaluate :: a -> IO a
mapException :: (Exception -> Exception) -> a -> a
ioErrors :: Exception -> Maybe IOError
arithExceptions :: Exception -> Maybe ArithException
errorCalls :: Exception -> Maybe String
dynExceptions :: Exception -> Maybe Dynamic
assertions :: Exception -> Maybe String
asyncExceptions :: Exception -> Maybe AsyncException
userErrors :: Exception -> Maybe String
throwDyn :: Typeable exception => exception -> b
throwDynTo :: Typeable exception => ThreadId -> exception -> IO ()
catchDyn :: Typeable exception => IO a -> (exception -> IO a) -> IO a
block :: IO a -> IO a
unblock :: IO a -> IO a
assert :: Bool -> a -> a
bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c
bracket_ :: IO a -> IO b -> IO c -> IO c
finally :: IO a -> IO b -> IO a

The Exception type
data Exception

The type of exceptions. Every kind of system-generated exception has a constructor in the `Exception` type, and values of other types may be injected into `Exception` by coercing them to `Dynamic` (see the section on Dynamic Exceptions: Control.Exception#DynamicExceptions).
Constructors

ArithException ArithException | Exceptions raised by arithmetic operations. (NOTE: GHC currently does not throw `ArithException`s except for `DivideByZero`).
ArrayException ArrayException | Exceptions raised by array-related operations. (NOTE: GHC currently does not throw `ArrayException`s).
AssertionFailed String | This exception is thrown by the `assert` operation when the condition fails. The `String` argument contains the location of the assertion in the source program.
AsyncException AsyncException | Asynchronous exceptions (see section on Asynchronous Exceptions: Control.Exception#AsynchronousExceptions).
BlockedOnDeadMVar | The current thread was executing a call to `takeMVar` that could never return, because there are no other references to this `MVar`.
Deadlock | There are no runnable threads, so the program is deadlocked. The `Deadlock` exception is raised in the main thread only (see also: Control.Concurrent).
DynException Dynamic | Dynamically typed exceptions (see section on Dynamic Exceptions: Control.Exception#DynamicExceptions).
ErrorCall String | The `ErrorCall` exception is thrown by `error`. The `String` argument of `ErrorCall` is the string passed to `error` when it was called.
ExitException ExitCode | The `ExitException` exception is thrown by `exitWith` (and `exitFailure`). The `ExitCode` argument is the value passed to `exitWith`. An unhandled `ExitException` exception in the main thread will cause the program to be terminated with the given exit code.
IOException IOException | These are the standard IO exceptions generated by Haskell's `IO` operations. See also System.IO.Error.
NoMethodError String | An attempt was made to invoke a class method which has no definition in this instance, and there was no default definition given in the class declaration. GHC issues a warning when you compile an instance which has missing methods.
NonTermination | The current thread is stuck in an infinite loop. This exception may or may not be thrown when the program is non-terminating.
PatternMatchFail String | A pattern matching failure. The `String` argument should contain a descriptive message including the function name, source file and line number.
RecConError String | An attempt was made to evaluate a field of a record for which no value was given at construction time. The `String` argument gives the location of the record construction in the source program.
RecSelError String | A field selection was attempted on a constructor that doesn't have the requested field. This can happen with multi-constructor records when one or more fields are missing from some of the constructors. The `String` argument gives the location of the record selection in the source program.
RecUpdError String | An attempt was made to update a field in a record, where the record doesn't have the requested field. This can only occur with multi-constructor records, when one or more fields are missing from some of the constructors. The `String` argument gives the location of the record update in the source program.

Instances

Typeable Exception
Show Exception
Eq Exception

data IOException

Exceptions that occur in the `IO` monad. An `IOException` records a more specific error type, a descriptive string and maybe the handle that was used when the error was flagged.
Instances

Typeable IOException
Eq IOException
Show IOException

data ArithException

The type of arithmetic exceptions
Constructors

Overflow |
Underflow |
LossOfPrecision |
DivideByZero |
Denormal |

Instances

Typeable ArithException
Show ArithException
Eq ArithException
Ord ArithException

data ArrayException

Exceptions generated by array operations
Constructors

IndexOutOfBounds String | An attempt was made to index an array outside its declared bounds.
UndefinedElement String | An attempt was made to evaluate an element of an array that had not been initialized.

Instances

Typeable ArrayException
Show ArrayException
Eq ArrayException
Ord ArrayException

data AsyncException

Asynchronous exceptions
Constructors

StackOverflow | The current thread's stack exceeded its limit. Since an exception has been raised, the thread's stack will certainly be below its limit again, but the programmer should take remedial action immediately.

HeapOverflow

The program's heap is reaching its limit, and the program should take action to reduce the amount of live data it has. Notes:

- It is undefined which thread receives this exception.
- GHC currently does not throw `HeapOverflow` exceptions.

ThreadKilled | This exception is raised by another thread calling `killThread`, or by the system if it needs to terminate the thread for some reason.

Instances

Typeable AsyncException
Show AsyncException
Eq AsyncException
Ord AsyncException

Throwing exceptions
throwIO :: Exception -> IO a

A variant of `throw` that can be used within the `IO` monad.

Although `throwIO` has a type that is an instance of the type of `throw`, the two functions are subtly different:

     throw e   `seq` return ()  ===> throw e
     throwIO e `seq` return ()  ===> return ()

The first example will cause the exception `e` to be raised, whereas the second one won't. In fact, `throwIO` will only cause an exception to be raised when it is used within the `IO` monad. The `throwIO` variant should be used in preference to `throw` to raise an exception within the `IO` monad because it guarantees ordering with respect to other `IO` operations, whereas `throw` does not.

throw :: Exception -> a
Throw an exception. Exceptions may be thrown from purely functional code, but may only be caught within the `IO` monad.
ioError :: IOError -> IO a
Raise an `IOError` in the `IO` monad.
throwTo :: ThreadId -> Exception -> IO ()

`throwTo` raises an arbitrary exception in the target thread (GHC only).

`throwTo` does not return until the exception has been raised in the target thread. The calling thread can thus be certain that the target thread has received the exception. This is a useful property to know when dealing with race conditions: eg. if there are two threads that can kill each other, it is guaranteed that only one of the threads will get to kill the other.

Catching Exceptions
There are several functions for catching and examining exceptions; all of them may only be used from within the `IO` monad.
The `catch` functions
catch

:: IO a | The computation to run
-> (Exception -> IO a) | Handler to invoke if an exception is raised
-> IO a |

This is the simplest of the exception-catching functions. It takes a single argument, runs it, and if an exception is raised the "handler" is executed, with the value of the exception passed as an argument. Otherwise, the result is returned as normal. For example:

       catch (openFile f ReadMode)
           (\e -> hPutStr stderr (\"Couldn\'t open \"++f++\": \" ++ show e))

For catching exceptions in pure (non-`IO`) expressions, see the function `evaluate`.

Note that due to Haskell's unspecified evaluation order, an expression may return one of several possible exceptions: consider the expression `error "urk" + 1 `div` 0`. Does `catch` execute the handler passing `ErrorCall "urk"`, or `ArithError DivideByZero`?

The answer is "either": `catch` makes a non-deterministic choice about which exception to catch. If you call it again, you might get a different exception back. This is ok, because `catch` is an `IO` computation.

Note that `catch` catches all types of exceptions, and is generally used for "cleaning up" before passing on the exception using `throwIO`. It is not good practice to discard the exception and continue, without first checking the type of the exception (it might be a `ThreadKilled`, for example). In this case it is usually better to use `catchJust` and select the kinds of exceptions to catch.

Also note that The Prelude also exports a function called `catch` which has the same type as `catch`, the difference being that the Prelude version only catches the IO and user families of exceptions (as required by Haskell 98). We recommend either hiding the Prelude version of `catch` when importing Control.Exception, or importing Control.Exception qualified, to avoid name-clashes.

catchJust

:: (Exception -> Maybe b) | Predicate to select exceptions
-> IO a | Computation to run
-> (b -> IO a) | Handler
-> IO a |

The function `catchJust` is like `catch`, but it takes an extra argument which is an exception predicate, a function which selects which type of exceptions we're interested in. There are some predefined exception predicates for useful subsets of exceptions: `ioErrors`, `arithExceptions`, and so on. For example, to catch just calls to the `error` function, we could use

       result <- catchJust errorCalls thing_to_try handler

Any other exceptions which are not matched by the predicate are re-raised, and may be caught by an enclosing `catch` or `catchJust`.

The `handle` functions
handle :: (Exception -> IO a) -> IO a -> IO a

A version of `catch` with the arguments swapped around; useful in situations where the code for the handler is shorter. For example:

       do handle (\e -> exitWith (ExitFailure 1)) $
    	  ...

handleJust :: (Exception -> Maybe b) -> (b -> IO a) -> IO a -> IO a
A version of `catchJust` with the arguments swapped around (see `handle`).
The `try` functions
try :: IO a -> IO (Either Exception a)

Similar to `catch`, but returns an `Either` result which is `(Right a)` if no exception was raised, or `(Left e)` if an exception was raised and its value is `e`.

      try a = catch (Right \`liftM\` a) (return . Left)

Note: as with `catch`, it is only polite to use this variant if you intend to re-throw the exception after performing whatever cleanup is needed. Otherwise, `tryJust` is generally considered to be better.

tryJust :: (Exception -> Maybe b) -> IO a -> IO (Either b a)
A variant of `try` that takes an exception predicate to select which exceptions are caught (c.f. `catchJust`). If the exception does not match the predicate, it is re-thrown.
The `evaluate` function
evaluate :: a -> IO a

Forces its argument to be evaluated, and returns the result in the `IO` monad. It can be used to order evaluation with respect to other `IO` operations; its semantics are given by

       evaluate undefined `seq` return ()  ==> return ()
       catch (evaluate undefined) (\e -> return ())  ==> return ()

NOTE: `(evaluate a)` is not the same as `(a `seq` return a)`.

The `mapException` function
mapException :: (Exception -> Exception) -> a -> a
This function maps one exception into another as proposed in the paper "A semantics for imprecise exceptions".
Exception predicates
These pre-defined predicates may be used as the first argument to `catchJust`, `tryJust`, or `handleJust` to select certain common classes of exceptions.
ioErrors :: Exception -> Maybe IOError
arithExceptions :: Exception -> Maybe ArithException
errorCalls :: Exception -> Maybe String
dynExceptions :: Exception -> Maybe Dynamic
assertions :: Exception -> Maybe String
asyncExceptions :: Exception -> Maybe AsyncException
userErrors :: Exception -> Maybe String
Dynamic exceptions
Because the `Exception` datatype is not extensible, there is an interface for throwing and catching exceptions of type `Dynamic` (see Data.Dynamic) which allows exception values of any type in the `Typeable` class to be thrown and caught.
throwDyn :: Typeable exception => exception -> b
Raise any value as an exception, provided it is in the `Typeable` class.
throwDynTo :: Typeable exception => ThreadId -> exception -> IO ()
A variant of `throwDyn` that throws the dynamic exception to an arbitrary thread (GHC only: c.f. `throwTo`).
catchDyn :: Typeable exception => IO a -> (exception -> IO a) -> IO a
Catch dynamic exceptions of the required type. All other exceptions are re-thrown, including dynamic exceptions of the wrong type. When using dynamic exceptions it is advisable to define a new datatype to use for your exception type, to avoid possible clashes with dynamic exceptions used in other libraries.
Asynchronous Exceptions

Asynchronous exceptions are so-called because they arise due to external influences, and can be raised at any point during execution. `StackOverflow` and `HeapOverflow` are two examples of system-generated asynchronous exceptions.

The primary source of asynchronous exceptions, however, is `throwTo`:

      throwTo :: ThreadId -> Exception -> IO ()

`throwTo` (also `throwDynTo` and `killThread`) allows one running thread to raise an arbitrary exception in another thread. The exception is therefore asynchronous with respect to the target thread, which could be doing anything at the time it receives the exception. Great care should be taken with asynchronous exceptions; it is all too easy to introduce race conditions by the over zealous use of `throwTo`.

Asynchronous exception control
The following two functions allow a thread to control delivery of asynchronous exceptions during a critical region.
block :: IO a -> IO a
Applying `block` to a computation will execute that computation with asynchronous exceptions blocked. That is, any thread which attempts to raise an exception in the current thread will be blocked until asynchronous exceptions are enabled again. There's no need to worry about re-enabling asynchronous exceptions; that is done automatically on exiting the scope of `block`.
unblock :: IO a -> IO a
To re-enable asynchronous exceptions inside the scope of `block`, `unblock` can be used. It scopes in exactly the same way, so on exit from `unblock` asynchronous exception delivery will be disabled again.
Applying `block` to an exception handler

There's an implied `block` around every exception handler in a call to one of the `catch` family of functions. This is because that is what you want most of the time - it eliminates a common race condition in starting an exception handler, because there may be no exception handler on the stack to handle another exception if one arrives immediately. If asynchronous exceptions are blocked on entering the handler, though, we have time to install a new exception handler before being interrupted. If this weren't the default, one would have to write something like

          block (
               catch (unblock (...))
                          (\e -> handler)
          )

If you need to unblock asynchronous exceptions again in the exception handler, just use `unblock` as normal.

Note that `try` and friends do not have a similar default, because there is no exception handler in this case. If you want to use `try` in an asynchronous-exception-safe way, you will need to use `block`.

Interruptible operations

Some operations are interruptible, which means that they can receive asynchronous exceptions even in the scope of a `block`. Any function which may itself block is defined as interruptible; this includes `takeMVar` (but not `tryTakeMVar`), and most operations which perform some I/O with the outside world. The reason for having interruptible operations is so that we can write things like

          block (
             a <- takeMVar m
             catch (unblock (...))
                   (\e -> ...)
          )

if the `takeMVar` was not interruptible, then this particular combination could lead to deadlock, because the thread itself would be blocked in a state where it can't receive any asynchronous exceptions. With `takeMVar` interruptible, however, we can be safe in the knowledge that the thread can receive exceptions right up until the point when the `takeMVar` succeeds. Similar arguments apply for other interruptible operations like `openFile`.

Assertions
assert :: Bool -> a -> a

If the first argument evaluates to `True`, then the result is the second argument. Otherwise an `AssertionFailed` exception is raised, containing a `String` with the source file and line number of the call to assert.

Assertions can normally be turned on or off with a compiler flag (for GHC, assertions are normally on unless the `-fignore-asserts` option is give). When assertions are turned off, the first argument to `assert` is ignored, and the second argument is returned as the result.

Utilities
bracket

:: IO a | computation to run first ("acquire resource")
-> (a -> IO b) | computation to run last ("release resource")
-> (a -> IO c) | computation to run in-between
-> IO c |

When you want to acquire a resource, do some work with it, and then release the resource, it is a good idea to use `bracket`, because `bracket` will install the necessary exception handler to release the resource in the event that an exception is raised during the computation. If an exception is raised, then `bracket` will re-raise the exception (after performing the release).

A common example is opening a file:

     bracket
       (openFile "filename" ReadMode)
       (hClose)
       (\handle -> do { ... })

The arguments to `bracket` are in this order so that we can partially apply it, e.g.:

     withFile name = bracket (openFile name) hClose

bracket_ :: IO a -> IO b -> IO c -> IO c
A variant of `bracket` where the return value from the first computation is not required.
finally

:: IO a | computation to run first
-> IO b | computation to run afterward (even if an exception was raised)
-> IO a |
A specialised variant of `bracket` with just a computation to run afterward.

Produced by Haddock version 0.6