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.

Thrown when the runtime system detects that the computation is
guaranteed not to terminate. Note that there is no guarantee that
the runtime system will notice whether any given computation is
guaranteed to terminate or not.

A record selector was applied to a constructor without the
appropriate field. This can only happen with a datatype with
multiple constructors, where some fields are in one constructor
but not another. The String gives information about the source
location of the record selector.

A record update was performed on a constructor without the
appropriate field. This can only happen with a datatype with
multiple constructors, where some fields are in one constructor
but not another. The String gives information about the source
location of the record update.

Throwing exceptions

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.

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.

Whatever work the target thread was doing when the exception was
raised is not lost: the computation is suspended until required by
another thread.

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 mask 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 9 of the paper.
Like any blocking operation, throwTo is therefore interruptible (see Section 5.3 of
the paper). Unlike other interruptible operations, however, throwTo
is always interruptible, even if it does not actually block.

There is no guarantee that the exception will be delivered promptly,
although the runtime will endeavour to ensure that arbitrary
delays don't occur. In GHC, an exception can only be raised when a
thread reaches a safe point, where a safe point is where memory
allocation occurs. Some loops do not perform any memory allocation
inside the loop and therefore cannot be interrupted by a throwTo.

Blocked throwTo is fair: if multiple threads are trying to throw an
exception to the same target thread, they will succeed in FIFO order.

Catching Exceptions

The catch functions

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:

Note that we have to give a type signature to e, or the program
will not typecheck as the type is ambiguous. While it is possible
to catch exceptions of any type, see the previous section "Catching all
exceptions" for an explanation of the problems with doing so.

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

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

The answer is "it might throw either"; the choice is
non-deterministic. If you are catching any type of exception then you
might catch either. If you are calling catch with type
IO Int -> (ArithException -> IO Int) -> IO Int then the handler may
get run with DivideByZero as an argument, or an ErrorCall "urk"
exception may be propogated further up. If you call it again, you
might get a the opposite behaviour. This is ok, because catch is an
IO computation.

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).

The try functions

Similar to catch, but returns an Either result which is
(Right a) if no exception of type e was raised, or (Left ex)
if an exception of type e was raised and its value is ex.
If any other type of exception is raised than it will be propogated
up to the next enclosing exception handler.

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

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).

The evaluate function

Forces its argument to be evaluated to weak head normal form 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

Asynchronous Exceptions

Asynchronous exception control

Executes an IO computation with asynchronous
exceptions masked. 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 unmasked again.

The argument passed to mask is a function that takes as its
argument another function, which can be used to restore the
prevailing masking state within the context of the masked
computation. For example, a common way to use mask is to protect
the acquisition of a resource:

This code guarantees that acquire is paired with release, by masking
asynchronous exceptions for the critical parts. (Rather than write
this code yourself, it would be better to use
Control.Exception.bracket which abstracts the general pattern).

Note that the restore action passed to the argument to mask
does not necessarily unmask asynchronous exceptions, it just
restores the masking state to that of the enclosing context. Thus
if asynchronous exceptions are already masked, mask cannot be used
to unmask exceptions again. This is so that if you call a library function
with exceptions masked, you can be sure that the library call will not be
able to unmask exceptions again. If you are writing library code and need
to use asynchronous exceptions, the only way is to create a new thread;
see Control.Concurrent.forkIOUnmasked.

Asynchronous exceptions may still be received while in the masked
state if the masked thread blocks in certain ways; see
Control.Exception.

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

Like mask, but the masked computation is not interruptible (see
Control.Exception). THIS SHOULD BE USED WITH
GREAT CARE, because if a thread executing in uninterruptibleMask
blocks for any reason, then the thread (and possibly the program,
if this is the main thread) will be unresponsive and unkillable.
This function should only be necessary if you need to mask
exceptions around an interruptible operation, and you can guarantee
that the interruptible operation will only block for a short period
of time.

(deprecated) Asynchronous exception control

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 unblocked 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.

Assertions

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

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).