Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://hackage.haskell.org/packages/archive/base/4.5.0.0/doc/html/Control-OldException.html below:

Control.OldException

data Exception Source

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

Constructors

Exceptions raised by arithmetic operations. (NOTE: GHC currently does not throw ArithExceptions except for DivideByZero).

Exceptions raised by array-related operations. (NOTE: GHC currently does not throw ArrayExceptions).

This exception is thrown by the assert operation when the condition fails. The String argument contains the location of the assertion in the source program.

Asynchronous exceptions (see section on Asynchronous Exceptions: Control.OldException).

The current thread was executing a call to takeMVar that could never return, because there are no other references to this MVar.

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.

The runtime detected an attempt to nest one STM transaction inside another one, presumably due to the use of unsafePeformIO with atomically.

There are no runnable threads, so the program is deadlocked. The Deadlock exception is raised in the main thread only (see also: Control.Concurrent).

Dynamically typed exceptions (see section on Dynamic Exceptions: Control.OldException).

The ErrorCall exception is thrown by error. The String argument of ErrorCall is the string passed to error when it was called.

The ExitException exception is thrown by exitWith (and exitFailure). The ExitCode argument is the value passed to exitWith. An unhandled ExitException exception in the main thread will cause the program to be terminated with the given exit code.

These are the standard IO exceptions generated by Haskell's IO operations. See also System.IO.Error.

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.

The current thread is stuck in an infinite loop. This exception may or may not be thrown when the program is non-terminating.

A pattern matching failure. The String argument should contain a descriptive message including the function name, source file and line number.

An attempt was made to evaluate a field of a record for which no value was given at construction time. The String argument gives the location of the record construction in the source program.

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 String argument gives the location of the record selection in the source program.

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 String argument gives the location of the record update in the source program.

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 AsyncException Source

Asynchronous exceptions.

Constructors

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.

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.

This exception is raised by another thread calling killThread, or by the system if it needs to terminate the thread for some reason.

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

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. However, in GHC a foreign call can be annotated as interruptible, in which case a throwTo will cause the RTS to attempt to cause the call to return; see the GHC documentation for more details.

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.

If the target of throwTo is the calling thread, then the behaviour is the same as throwIO, except that the exception is thrown as an asynchronous exception. This means that if there is an enclosing pure computation, which would be the case if the current IO operation is inside unsafePerformIO or unsafeInterleaveIO, that computation is not permanently replaced by the exception, but is suspended as if it had received an asynchronous exception.

Note that if throwTo is called with the current thread as the target, the exception will be thrown even if the thread is currently inside mask or uninterruptibleMask.

There are several functions for catching and examining exceptions; all of them may only be used from within the IO monad.

catchSource

Arguments

The computation to run

Handler to invoke if an exception is raised

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

catchJustSource

Arguments

Predicate to select exceptions

Computation to run

Handler

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.

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

try :: IO a -> IO (Either Exception a)Source

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

evaluate :: a -> IO aSource

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

These pre-defined predicates may be used as the first argument to catchJust, tryJust, or handleJust to select certain common classes of exceptions.

ioErrors :: Exception -> Maybe IOErrorSource

arithExceptions :: Exception -> Maybe ArithExceptionSource

errorCalls :: Exception -> Maybe StringSource

dynExceptions :: Exception -> Maybe DynamicSource

assertions :: Exception -> Maybe StringSource

asyncExceptions :: Exception -> Maybe AsyncExceptionSource

userErrors :: Exception -> Maybe StringSource

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.

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

The following two functions allow a thread to control delivery of asynchronous exceptions during a critical region.

block :: IO a -> IO aSource

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

unblock :: IO a -> IO aSource

Note: this function is deprecated, please use mask instead.

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.

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.

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 takeMVar (but not 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 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 takeMVar interruptible, however, we can be safe in the knowledge that the thread can receive exceptions right up until the point when the takeMVar succeeds. Similar arguments apply for other interruptible operations like openFile.

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.

bracketSource

Arguments

computation to run first ("acquire resource")

computation to run last ("release resource")

computation to run in-between

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

bracketOnErrorSource

Arguments

computation to run first ("acquire resource")

computation to run last ("release resource")

computation to run in-between

Like bracket, but only performs the final action if there was an exception raised by the in-between computation.

finallySource

Arguments

computation to run first

computation to run afterward (even if an exception was raised)

A specialised variant of bracket with just a computation to run afterward.

setUncaughtExceptionHandler :: (Exception -> IO ()) -> IO ()Source

getUncaughtExceptionHandler :: IO (Exception -> IO ())Source

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4