base-4.0.0.0: Basic librariesContentsIndex
Control.Exception
Portabilitynon-portable (extended exceptions)
Stabilityexperimental
Maintainerlibraries@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
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.

In addition to exceptions thrown by IO operations, exceptions may be thrown by pure code (imprecise exceptions) or by external events (asynchronous exceptions), but may only be caught in the IO monad. For more details, see:

  • A semantics for imprecise exceptions, by Simon Peyton Jones, Alastair Reid, Tony Hoare, Simon Marlow, Fergus Henderson, in PLDI'99.
  • Asynchronous exceptions in Haskell, by Simon Marlow, Simon Peyton Jones, Andy Moran and John Reppy, in PLDI'01.
Synopsis
data SomeException = forall e . Exception e => SomeException e
class (Typeable e, Show e) => Exception e where
toException :: e -> SomeException
fromException :: SomeException -> Maybe e
data IOException
data ArithException
= Overflow
| Underflow
| LossOfPrecision
| DivideByZero
| Denormal
data ArrayException
= IndexOutOfBounds String
| UndefinedElement String
data AssertionFailed = AssertionFailed String
data AsyncException
= StackOverflow
| HeapOverflow
| ThreadKilled
| UserInterrupt
data NonTermination = NonTermination
data NestedAtomically = NestedAtomically
data BlockedOnDeadMVar = BlockedOnDeadMVar
data BlockedIndefinitely = BlockedIndefinitely
data Deadlock = Deadlock
data NoMethodError = NoMethodError String
data PatternMatchFail = PatternMatchFail String
data RecConError = RecConError String
data RecSelError = RecSelError String
data RecUpdError = RecUpdError String
data ErrorCall = ErrorCall String
throwIO :: Exception e => e -> IO a
throw :: Exception e => e -> a
ioError :: IOError -> IO a
throwTo :: Exception e => ThreadId -> e -> IO ()
catch :: Exception e => IO a -> (e -> IO a) -> IO a
catches :: IO a -> [Handler a] -> IO a
data Handler a = forall e . Exception e => Handler (e -> IO a)
catchJust :: Exception e => (e -> Maybe b) -> IO a -> (b -> IO a) -> IO a
handle :: Exception e => (e -> IO a) -> IO a -> IO a
handleJust :: Exception e => (e -> Maybe b) -> (b -> IO a) -> IO a -> IO a
try :: Exception e => IO a -> IO (Either e a)
tryJust :: Exception e => (e -> Maybe b) -> IO a -> IO (Either b a)
onException :: IO a -> IO b -> IO a
evaluate :: a -> IO a
mapException :: (Exception e1, Exception e2) => (e1 -> e2) -> a -> a
block :: IO a -> IO a
unblock :: IO a -> IO a
blocked :: IO Bool
assert :: Bool -> a -> a
bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c
bracket_ :: IO a -> IO b -> IO c -> IO c
bracketOnError :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c
finally :: IO a -> IO b -> IO a
The Exception type
data SomeException
Constructors
forall e . Exception e => SomeException e
show/hide Instances
class (Typeable e, Show e) => Exception e where
Methods
toException :: e -> SomeException
fromException :: SomeException -> Maybe e
show/hide Instances
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.
show/hide Instances
data ArithException
The type of arithmetic exceptions
Constructors
Overflow
Underflow
LossOfPrecision
DivideByZero
Denormal
show/hide Instances
data ArrayException
Exceptions generated by array operations
Constructors
IndexOutOfBounds StringAn attempt was made to index an array outside its declared bounds.
UndefinedElement StringAn attempt was made to evaluate an element of an array that had not been initialized.
show/hide Instances
data AssertionFailed
Constructors
AssertionFailed String
show/hide Instances
data AsyncException
Asynchronous exceptions
Constructors
StackOverflowThe 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.
ThreadKilledThis exception is raised by another thread calling Control.Concurrent.killThread, or by the system if it needs to terminate the thread for some reason.
UserInterruptThis exception is raised by default in the main thread of the program when the user requests to terminate the program via the usual mechanism(s) (e.g. Control-C in the console).
show/hide Instances
data NonTermination
Constructors
NonTermination
show/hide Instances
data NestedAtomically
Constructors
NestedAtomically
show/hide Instances
data BlockedOnDeadMVar
Constructors
BlockedOnDeadMVar
show/hide Instances
data BlockedIndefinitely
Constructors
BlockedIndefinitely
show/hide Instances
data Deadlock
Constructors
Deadlock
show/hide Instances
data NoMethodError
Constructors
NoMethodError String
show/hide Instances
data PatternMatchFail
Constructors
PatternMatchFail String
show/hide Instances
data RecConError
Constructors
RecConError String
show/hide Instances
data RecSelError
Constructors
RecSelError String
show/hide Instances
data RecUpdError
Constructors
RecUpdError String
show/hide Instances
data ErrorCall
Constructors
ErrorCall String
show/hide Instances
Throwing exceptions
throwIO :: Exception e => e -> 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` x  ===> throw e
 throwIO e `seq` x  ===> x

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 e => e -> 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 :: Exception e => ThreadId -> e -> 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.

If the target thread is currently making a foreign call, then the exception will not be raised (and hence throwTo will not return) until the call has completed. This is the case regardless of whether the call is inside a block or not.

Important note: the behaviour of throwTo differs from that described in the paper "Asynchronous exceptions in Haskell" (http://research.microsoft.com/~simonpj/Papers/asynch-exns.htm). In the paper, throwTo is non-blocking; but the library implementation adopts a more synchronous design in which throwTo does not return until the exception is received by the target thread. The trade-off is discussed in Section 8 of the paper. Like any blocking operation, throwTo is therefore interruptible (see Section 4.3 of the paper).

There is currently no guarantee that the exception delivered by throwTo will be delivered at the first possible opportunity. In particular, if a thread may unblock and then re-block exceptions (using unblock and block) without receiving a pending throwTo. This is arguably undesirable behaviour.

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
:: Exception e
=> IO aThe computation to run
-> e -> IO aHandler 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 Prelude.catch with a similar type to Control.Exception.catch, except 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 Prelude.catch when importing Control.Exception:

 import Prelude hiding (catch)

or importing Control.Exception qualified, to avoid name-clashes:

 import qualified Control.Exception as C

and then using C.catch

catches :: IO a -> [Handler a] -> IO a
data Handler a
Constructors
forall e . Exception e => Handler (e -> IO a)
catchJust
:: Exception e
=> e -> Maybe bPredicate to select exceptions
-> IO aComputation to run
-> b -> IO aHandler
-> 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.

   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 e => (e -> 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 e => (e -> Maybe b) -> (b -> IO a) -> IO a -> IO a
A version of catchJust with the arguments swapped around (see handle).
The try functions
try :: Exception e => IO a -> IO (Either e 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.

Also note that System.IO.Error also exports a function called System.IO.Error.try with a similar type to Control.Exception.try, except that it catches only the IO and user families of exceptions (as required by the Haskell 98 IO module).

tryJust :: Exception e => (e -> 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.
onException :: IO a -> IO b -> IO a
The evaluate function
evaluate :: a -> IO a

Forces its argument to be evaluated when the resultant IO action is executed. It can be used to order evaluation with respect to other IO operations; its semantics are given by

   evaluate x `seq` y    ==>  y
   evaluate x `catch` f  ==>  (return $! x) `catch` f
   evaluate x >>= f      ==>  (return $! x) >>= f

Note: the first equation implies that (evaluate x) is not the same as (return $! x). A correct definition is

   evaluate x = (return $! x) >>= return
The mapException function
mapException :: (Exception e1, Exception e2) => (e1 -> e2) -> a -> a
This function maps one exception into another as proposed in the paper "A semantics for imprecise exceptions".
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 Control.Concurrent.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 with Control.Exception.throwTo 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.

Threads created by Control.Concurrent.forkIO inherit the blocked state from the parent; that is, to start a thread in blocked mode, use block $ forkIO .... This is particularly useful if you need to establish an exception handler in the forked thread before any asynchronous exceptions are received.

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.
blocked :: IO Bool
returns True if asynchronous exceptions are blocked in the current thread.
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 Control.Concurrent.MVar.takeMVar (but not Control.Concurrent.MVar.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 Control.Concurrent.MVar.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 Control.Concurrent.MVar.takeMVar interruptible, however, we can be safe in the knowledge that the thread can receive exceptions right up until the point when the Control.Concurrent.MVar.takeMVar succeeds. Similar arguments apply for other interruptible operations like System.IO.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 optimisation is turned on with -O or the -fignore-asserts option is given). When assertions are turned off, the first argument to assert is ignored, and the second argument is returned as the result.

Utilities
bracket
::
=> IO acomputation to run first ("acquire resource")
-> a -> IO bcomputation to run last ("release resource")
-> a -> IO ccomputation 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 mode = bracket (openFile name mode) 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.
bracketOnError
::
=> IO acomputation to run first ("acquire resource")
-> a -> IO bcomputation to run last ("release resource")
-> a -> IO ccomputation to run in-between
-> IO c
Like bracket, but only performs the final action if there was an exception raised by the in-between computation.
finally
::
=> IO acomputation to run first
-> IO bcomputation 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 2.3.0