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

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

Control.Exception

data SomeException Source

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.

class (Typeable e, Show e) => Exception e whereSource

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

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

data NonTermination Source

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.

data NestedAtomically Source

Thrown when the program attempts to call atomically, from the stm package, inside another call to atomically.

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.

data Deadlock Source

There are no runnable threads, so the program is deadlocked. The Deadlock exception is raised in the main thread only.

data NoMethodError Source

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.

data PatternMatchFail Source

A pattern match failed. The String gives information about the source location of the pattern.

data RecConError Source

An uninitialised record field was used. The String gives information about the source location where the record was constructed.

data RecSelError Source

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.

data RecUpdError Source

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.

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.

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.

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.

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.

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 (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 section "Catching all exceptions" (in Control.Exception) 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 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.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

catches :: IO a -> [Handler a] -> IO aSource

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

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.

 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.

handle :: Exception e => (e -> 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 (\NonTermination -> exitWith (ExitFailure 1)) $
      ...

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

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

mapException :: (Exception e1, Exception e2) => (e1 -> e2) -> a -> aSource

This function maps one exception into another as proposed in the paper "A semantics for imprecise 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 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 functions allow a thread to control delivery of asynchronous exceptions during a critical region.

mask :: ((forall a. IO a -> IO a) -> IO b) -> IO bSource

Executes an IO computation with asynchronous exceptions masked. That is, any thread which attempts to raise an exception in the current thread with throwTo will be blocked until asynchronous exceptions are unmasked again.

The argument passed to mask is a function that takes as its argument another function, which can be used to restore the prevailing masking state within the context of the masked computation. For example, a common way to use mask is to protect the acquisition of a resource:

 mask $ \restore -> do
     x <- acquire
     restore (do_something_with x) `onException` release
     release

This code guarantees that acquire is paired with release, by masking asynchronous exceptions for the critical parts. (Rather than write this code yourself, it would be better to use bracket which abstracts the general pattern).

Note that the restore action passed to the argument to mask does not necessarily unmask asynchronous exceptions, it just restores the masking state to that of the enclosing context. Thus if asynchronous exceptions are already masked, mask cannot be used to unmask exceptions again. This is so that if you call a library function with exceptions masked, you can be sure that the library call will not be able to unmask exceptions again. If you are writing library code and need to use asynchronous exceptions, the only way is to create a new thread; see forkIOWithUnmask.

Asynchronous exceptions may still be received while in the masked state if the masked thread blocks in certain ways; see Control.Exception.

Threads created by forkIO inherit the masked state from the parent; that is, to start a thread in blocked mode, use mask_ $ forkIO .... This is particularly useful if you need to establish an exception handler in the forked thread before any asynchronous exceptions are received. To create a a new thread in an unmasked state use forkIOUnmasked.

uninterruptibleMask :: ((forall a. IO a -> IO a) -> IO b) -> IO bSource

Like mask, but the masked computation is not interruptible (see Control.Exception). THIS SHOULD BE USED WITH GREAT CARE, because if a thread executing in uninterruptibleMask blocks for any reason, then the thread (and possibly the program, if this is the main thread) will be unresponsive and unkillable. This function should only be necessary if you need to mask exceptions around an interruptible operation, and you can guarantee that the interruptible operation will only block for a short period of time.

data MaskingState Source

Describes the behaviour of a thread when an asynchronous exception is received.

allowInterrupt :: IO ()Source

When invoked inside mask, this function allows a blocked asynchronous exception to be raised, if one exists. It is equivalent to performing an interruptible operation (see ), but does not involve any actual blocking.

When called outside mask, or inside uninterruptibleMask, this function has no effect.

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.

blocked :: IO BoolSource

returns True if asynchronous exceptions are blocked in the current thread.

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 masked 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, restore can be used there too.

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

It is useful to think of mask not as a way to completely prevent asynchronous exceptions, but as a way to switch from asynchronous mode to polling mode. The main difficulty with asynchronous exceptions is that they normally can occur anywhere, but within a mask an asynchronous exception is only raised by operations that are interruptible (or call other interruptible operations). In many cases these operations may themselves raise exceptions, such as I/O errors, so the caller will usually be prepared to handle exceptions arising from the operation anyway. To perfom an explicit poll for asynchronous exceptions inside mask, use allowInterrupt.

Sometimes it is too onerous to handle exceptions in the middle of a critical piece of stateful code. There are three ways to handle this kind of situation:

• Use STM. Since a transaction is always either completely executed or not at all, transactions are a good way to maintain invariants over state in the presence of asynchronous (and indeed synchronous) exceptions.
• Use mask, and avoid interruptible operations. In order to do this, we have to know which operations are interruptible. It is impossible to know for any given library function whether it might invoke an interruptible operation internally; so instead we give a list of guaranteed-not-to-be-interruptible operations below.
• Use uninterruptibleMask. This is generally not recommended, unless you can guarantee that any interruptible operations invoked during the scope of uninterruptibleMask can only ever block for a short time. Otherwise, uninterruptibleMask is a good way to make your program deadlock and be unresponsive to user interrupts.

The following operations are guaranteed not to be interruptible:

• operations on IORef from Data.IORef * STM transactions that do not use retry * everything from the Foreign modules * everything from Control.Exception * tryTakeMVar, tryPutMVar, isEmptyMVar * takeMVar if the MVar is definitely full, and conversely putMVar if the MVar is definitely empty * newEmptyMVar, newMVar * forkIO, forkIOUnmasked, myThreadId

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)
   (\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

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.

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