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.

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.

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

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

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

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.

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.