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.

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.

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.

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

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.

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

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

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

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

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.

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.

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.

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.

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.