Portability | non-portable (extended exceptions) |
---|---|
Stability | experimental |
Maintainer | libraries@haskell.org |
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.
- data Exception
- = ArithException ArithException
- | ArrayException ArrayException
- | AssertionFailed String
- | AsyncException AsyncException
- | BlockedOnDeadMVar
- | BlockedIndefinitely
- | NestedAtomically
- | 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
- data AsyncException
- throwIO :: Exception e => e -> IO a
- throw :: Exception e => e -> a
- ioError :: IOError -> IO a
- throwTo :: Exception e => ThreadId -> e -> 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
- bracketOnError :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c
- finally :: IO a -> IO b -> IO a
- setUncaughtExceptionHandler :: (Exception -> IO ()) -> IO ()
- getUncaughtExceptionHandler :: IO (Exception -> IO ())
The Exception type
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.OldException).
ArithException ArithException | Exceptions raised by arithmetic
operations. (NOTE: GHC currently does not throw
|
ArrayException ArrayException | Exceptions raised by array-related
operations. (NOTE: GHC currently does not throw
|
AssertionFailed String | This exception is thrown by the
|
AsyncException AsyncException | Asynchronous exceptions (see section on Asynchronous Exceptions: Control.OldException). |
BlockedOnDeadMVar | The current thread was executing a call to
|
BlockedIndefinitely | The current thread was waiting to retry an atomic memory transaction that could never become possible to complete because there are no other threads referring to any of the TVars involved. |
NestedAtomically | The runtime detected an attempt to nest one STM transaction
inside another one, presumably due to the use of
|
Deadlock | There are no runnable threads, so the program is
deadlocked. The |
DynException Dynamic | Dynamically typed exceptions (see section on Dynamic Exceptions: Control.OldException). |
ErrorCall String | The |
ExitException ExitCode | The |
IOException IOException | These are the standard IO exceptions generated by
Haskell's |
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 |
RecConError String | An attempt was made to evaluate a field of a record
for which no value was given at construction time. The
|
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
|
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
|
data IOException Source
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.
data ArithException Source
Arithmetic exceptions.
data ArrayException Source
Exceptions generated by array operations
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. |
data AsyncException Source
Asynchronous exceptions.
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:
|
ThreadKilled | This exception is raised by another thread
calling |
UserInterrupt | This 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). |
Throwing exceptions
throwIO :: Exception e => e -> IO aSource
A variant of throw
that can only 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 -> aSource
Throw an exception. Exceptions may be thrown from purely
functional code, but may only be caught within the IO
monad.
throwTo :: Exception e => ThreadId -> e -> IO ()Source
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.
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
There are several functions for catching and examining
exceptions; all of them may only be used from within the
IO
monad.
The catch
functions
:: 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
Prelude.catch
with a similar type to 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.OldException:
import Prelude hiding (catch)
or importing Control.OldException qualified, to avoid name-clashes:
import qualified Control.OldException as C
and then using C.catch
:: (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 aSource
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)) $ ...
The try
functions
try :: IO a -> IO (Either Exception a)Source
Similar to catch
, but returns an Either
result which is
(
if no exception was raised, or Right
a)(
if an
exception was raised and its value is Left
e)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 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
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 -> Exception) -> a -> aSource
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.
errorCalls :: Exception -> Maybe StringSource
assertions :: Exception -> Maybe StringSource
userErrors :: Exception -> Maybe StringSource
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 -> bSource
Raise any value as an exception, provided it is in the
Typeable
class.
catchDyn :: Typeable exception => IO a -> (exception -> IO a) -> IO aSource
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 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.
Note: this function is deprecated, please use mask
instead.
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.
Applying block
to an exception handler
There's an implied mask_
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
mask $ \restore -> catch (restore (...)) (\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
mask
.
Interruptible operations
Some operations are interruptible, which means that they can receive
asynchronous exceptions even in the scope of a mask
. 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
mask $ \restore -> do a <- takeMVar m catch (restore (...)) (\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 -> aSource
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
:: 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 mode = bracket (openFile name mode) hClose
bracket_ :: IO a -> IO b -> IO c -> IO cSource
A variant of bracket
where the return value from the first computation
is not required.
:: 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 |
Like bracket, but only performs the final action if there was an exception raised by the in-between computation.