|
Control.Exception | Portability | non-portable (extended exceptions) | Stability | experimental | Maintainer | libraries@haskell.org |
|
|
|
|
|
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.
- An Extensible Dynamically-Typed Hierarchy of Exceptions,
by Simon Marlow, in Haskell '06.
|
|
Synopsis |
|
|
|
|
The Exception type
|
|
|
The SomeException type is the root of the exception type hierarchy.
When an exception of type e is thrown, behind the scenes it is
encapsulated in a SomeException.
| Constructors | | Instances | |
|
|
|
Any type that you wish to throw or catch as an exception must be an
instance of the Exception class. The simplest case is a new exception
type directly below the root:
data MyException = ThisException | ThatException
deriving (Show, Typeable)
instance Exception MyException
The default method definitions in the Exception class do what we need
in this case. You can now throw and catch ThisException and
ThatException as exceptions:
*Main> throw ThisException catch e -> putStrLn ("Caught " ++ show (e :: MyException))
Caught ThisException
In more complicated examples, you may wish to define a whole hierarchy
of exceptions:
---------------------------------------------------------------------
-- Make the root exception type for all the exceptions in a compiler
data SomeCompilerException = forall e . Exception e => SomeCompilerException e
deriving Typeable
instance Show SomeCompilerException where
show (SomeCompilerException e) = show e
instance Exception SomeCompilerException
compilerExceptionToException :: Exception e => e -> SomeException
compilerExceptionToException = toException . SomeCompilerException
compilerExceptionFromException :: Exception e => SomeException -> Maybe e
compilerExceptionFromException x = do
SomeCompilerException a <- fromException x
cast a
---------------------------------------------------------------------
-- Make a subhierarchy for exceptions in the frontend of the compiler
data SomeFrontendException = forall e . Exception e => SomeFrontendException e
deriving Typeable
instance Show SomeFrontendException where
show (SomeFrontendException e) = show e
instance Exception SomeFrontendException where
toException = compilerExceptionToException
fromException = compilerExceptionFromException
frontendExceptionToException :: Exception e => e -> SomeException
frontendExceptionToException = toException . SomeFrontendException
frontendExceptionFromException :: Exception e => SomeException -> Maybe e
frontendExceptionFromException x = do
SomeFrontendException a <- fromException x
cast a
---------------------------------------------------------------------
-- Make an exception type for a particular frontend compiler exception
data MismatchedParentheses = MismatchedParentheses
deriving (Typeable, Show)
instance Exception MismatchedParentheses where
toException = frontendExceptionToException
fromException = frontendExceptionFromException
We can now catch a MismatchedParentheses exception as
MismatchedParentheses, SomeFrontendException or
SomeCompilerException, but not other types, e.g. IOException:
*Main> throw MismatchedParentheses catch e -> putStrLn ("Caught " ++ show (e :: MismatchedParentheses))
Caught MismatchedParentheses
*Main> throw MismatchedParentheses catch e -> putStrLn ("Caught " ++ show (e :: SomeFrontendException))
Caught MismatchedParentheses
*Main> throw MismatchedParentheses catch e -> putStrLn ("Caught " ++ show (e :: SomeCompilerException))
Caught MismatchedParentheses
*Main> throw MismatchedParentheses catch e -> putStrLn ("Caught " ++ show (e :: IOException))
*** Exception: MismatchedParentheses
| | Methods | | | Instances | |
|
|
|
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 | |
|
|
|
Arithmetic exceptions.
| Constructors | Overflow | | Underflow | | LossOfPrecision | | DivideByZero | | Denormal | |
| Instances | |
|
|
|
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 | |
|
|
|
|
|
|
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 Control.Concurrent.killThread, or by the system
if it needs to terminate the thread for some
reason.
| 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).
|
| Instances | |
|
|
|
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.
| Constructors | | Instances | |
|
|
|
Thrown when the program attempts to call atomically, from the stm
package, inside another call to atomically.
| Constructors | | Instances | |
|
|
data BlockedIndefinitelyOnMVar | Source |
|
The thread is blocked on an MVar, but there are no other references
to the MVar so it can't ever continue.
| Constructors | BlockedIndefinitelyOnMVar | |
| Instances | |
|
|
data BlockedIndefinitelyOnSTM | Source |
|
The thread is waiting to retry an STM transaction, but there are no
other references to any TVars involved, so it can't ever continue.
| Constructors | | Instances | |
|
|
|
There are no runnable threads, so the program is deadlocked.
The Deadlock exception is raised in the main thread only.
| Constructors | | Instances | |
|
|
|
A class method without a definition (neither a default definition,
nor a definition in the appropriate instance) was called. The
String gives information about which method it was.
| Constructors | | Instances | |
|
|
|
A pattern match failed. The String gives information about the
source location of the pattern.
| Constructors | | Instances | |
|
|
|
An uninitialised record field was used. The String gives
information about the source location where the record was
constructed.
| Constructors | | Instances | |
|
|
|
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.
| Constructors | | Instances | |
|
|
|
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.
| Constructors | | Instances | |
|
|
|
This is thrown when the user calls error. The String is the
argument given to error.
| Constructors | | Instances | |
|
|
Throwing exceptions
|
|
|
Throw an exception. Exceptions may be thrown from purely
functional code, but may only be caught within the IO monad.
|
|
|
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.
|
|
|
Raise an IOError in the IO monad.
|
|
|
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 9 of the paper.
Like any blocking operation, throwTo is therefore interruptible (see Section 5.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, 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.
Here's a rule of thumb for deciding which catch-style function to
use:
- If you want to do some cleanup in the event that an exception
is raised, use finally, bracket or onException.
- To recover after an exception and do something else, the best
choice is to use one of the try family.
- ... unless you are recovering from an asynchronous exception, in which
case use catch or catchJust.
The difference between using try and catch for recovery is that in
catch the handler is inside an implicit block (see "Asynchronous
Exceptions") which is important when catching asynchronous
exceptions, but when catching other kinds of exception it is
unnecessary. Furthermore it is possible to accidentally stay inside
the implicit block by tail-calling rather than returning from the
handler, which is why we recommend using try rather than catch for
ordinary exception recovery.
A typical use of tryJust for recovery looks like this:
do r <- tryJust (guard . isDoesNotExistError) $ getEnv "HOME"
case r of
Left e -> ...
Right home -> ...
|
|
Catching all exceptions
|
|
It is possible to catch all exceptions, by using the type SomeException:
catch f (\e -> ... (e :: SomeException) ...)
HOWEVER, this is normally not what you want to do!
For example, suppose you want to read a file, but if it doesn't exist
then continue as if it contained "". You might be tempted to just
catch all exceptions and return "" in the handler. However, this has
all sorts of undesirable consequences. For example, if the user
presses control-C at just the right moment then the UserInterrupt
exception will be caught, and the program will continue running under
the belief that the file contains "". Similarly, if another thread
tries to kill the thread reading the file then the ThreadKilled
exception will be ignored.
Instead, you should only catch exactly the exceptions that you really
want. In this case, this would likely be more specific than even
"any IO exception"; a permissions error would likely also want to be
handled differently. Instead, you would probably want something like:
e <- tryJust (guard . isDoesNotExistError) (readFile f)
let str = either (const "") id e
There are occassions when you really do need to catch any sort of
exception. However, in most cases this is just so you can do some
cleaning up; you aren't actually interested in the exception itself.
For example, if you open a file then you want to close it again,
whether processing the file executes normally or throws an exception.
However, in these cases you can use functions like bracket, finally
and onException, which never actually pass you the exception, but
just call the cleanup functions at the appropriate points.
But sometimes you really do need to catch any exception, and actually
see what the exception is. One example is at the very top-level of a
program, you may wish to catch any exception, print it to a logfile or
the screen, and then exit gracefully. For these cases, you can use
catch (or one of the other exception-catching functions) with the
SomeException type.
|
|
The catch functions
|
|
|
:: Exception e | | => IO a | The computation to run
| -> e -> 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 (readFile f)
(\e -> do let err = show (e :: IOException)
hPutStr stderr ("Warning: Couldn't open " ++ f ++ ": " ++ err)
return "")
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).
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
|
|
|
|
Sometimes you want to catch two different sorts of exception. You could
do something like
f = expr `catch` \ (ex :: ArithException) -> handleArith ex
`catch` \ (ex :: IOException) -> handleIO ex
However, there are a couple of problems with this approach. The first is
that having two exception handlers is inefficient. However, the more
serious issue is that the second exception handler will catch exceptions
in the first, e.g. in the example above, if handleArith throws an
IOException then the second exception handler will catch it.
Instead, we provide a function catches, which would be used thus:
f = expr `catches` [Handler (\ (ex :: ArithException) -> handleArith ex),
Handler (\ (ex :: IOException) -> handleIO ex)]
|
|
|
You need this when using catches.
| Constructors | |
|
|
|
:: Exception e | | => e -> 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.
catchJust (\e -> if isDoesNotExistErrorType (ioeGetErrorType e) then Just () else Nothing)
(readFile f)
(\_ -> do hPutStrLn stderr ("No such file: " ++ show f)
return "")
Any other exceptions which are not matched by the predicate
are re-raised, and may be caught by an enclosing
catch, catchJust, etc.
|
|
|
The handle functions
|
|
|
A version of catch with the arguments swapped around; useful in
situations where the code for the handler is shorter. For example:
do handle (\NonTermination -> exitWith (ExitFailure 1)) $
...
|
|
|
A version of catchJust with the arguments swapped around (see
handle).
|
|
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).
|
|
|
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
|
|
|
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
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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. Don't use try for
recovering from an asynchronous exception.
|
|
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
|
|
|
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)
(\fileHandle -> 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
|
|
|
|
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.
|
|
|
|
:: 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.
|
|
|
|
Like finally, but only performs the final action if there was an
exception raised by the computation.
|
|
Produced by Haddock version 2.6.1 |