Movatterモバイル変換

{-# LANGUAGE Trustworthy #-}{-# LANGUAGE NoImplicitPrelude, ExistentialQuantification #-}------------------------------------------------------------------------------- |-- Module      :  Control.Exception-- Copyright   :  (c) The University of Glasgow 2001-- License     :  BSD-style (see the file libraries/base/LICENSE)---- Maintainer  :  libraries@haskell.org-- Stability   :  experimental-- Portability :  non-portable (extended exceptions)---- 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/.-------------------------------------------------------------------------------moduleControl.Exception(-- * The Exception typeSomeException(..),Exception(..),-- classIOException,-- instance Eq, Ord, Show, Typeable, ExceptionArithException(..),-- instance Eq, Ord, Show, Typeable, ExceptionArrayException(..),-- instance Eq, Ord, Show, Typeable, ExceptionAssertionFailed(..),SomeAsyncException(..),AsyncException(..),-- instance Eq, Ord, Show, Typeable, ExceptionasyncExceptionToException,asyncExceptionFromException,NonTermination(..),NestedAtomically(..),BlockedIndefinitelyOnMVar(..),BlockedIndefinitelyOnSTM(..),AllocationLimitExceeded(..),CompactionFailed(..),Deadlock(..),NoMethodError(..),PatternMatchFail(..),RecConError(..),RecSelError(..),RecUpdError(..),ErrorCall(..),TypeError(..),-- * Throwing exceptionsthrow,throwIO,ioError,throwTo,-- * Catching Exceptions-- $catching-- ** Catching all exceptions-- $catchall-- ** The @catch@ functionscatch,catches,Handler(..),catchJust,-- ** The @handle@ functionshandle,handleJust,-- ** The @try@ functionstry,tryJust,-- ** The @evaluate@ functionevaluate,-- ** The @mapException@ functionmapException,-- * Asynchronous Exceptions-- $async-- ** Asynchronous exception control-- |The following functions allow a thread to control delivery of-- asynchronous exceptions during a critical region.mask,mask_,uninterruptibleMask,uninterruptibleMask_,MaskingState(..),getMaskingState,interruptible,allowInterrupt,-- *** Applying @mask@ to an exception handler-- $block_handler-- *** Interruptible operations-- $interruptible-- * Assertionsassert,-- * Utilitiesbracket,bracket_,bracketOnError,finally,onException,)whereimportControl.Exception.BaseimportGHC.BaseimportGHC.IO(interruptible)-- | You need this when using 'catches'.dataHandlera=foralle.Exceptione=>Handler(e->IOa)-- | @since 4.6.0.0instanceFunctorHandlerwherefmapf(Handlerh)=Handler(fmapf.h){- |Sometimes you want to catch two different sorts of exception. You coulddo something like> f = expr `catch` \ (ex :: ArithException) -> handleArith ex>          `catch` \ (ex :: IOException)    -> handleIO    exHowever, there are a couple of problems with this approach. The first isthat having two exception handlers is inefficient. However, the moreserious issue is that the second exception handler will catch exceptionsin 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)]-}catches::IOa->[Handlera]->IOacatchesiohandlers=io`catch`catchesHandlerhandlerscatchesHandler::[Handlera]->SomeException->IOacatchesHandlerhandlerse=foldrtryHandler(throwe)handlerswheretryHandler(Handlerhandler)res=casefromExceptioneofJuste'->handlere'Nothing->res-- ------------------------------------------------------------------------------- Catching exceptions{- $catchingThere are several functions for catching and examiningexceptions; all of them may only be used from within the'IO' monad.Here's a rule of thumb for deciding which catch-style function touse: * 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 'mask' (see \"AsynchronousExceptions\") which is important when catching asynchronousexceptions, but when catching other kinds of exception it isunnecessary.  Furthermore it is possible to accidentally stay insidethe implicit 'mask' by tail-calling rather than returning from thehandler, which is why we recommend using 'try' rather than 'catch' forordinary 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 -> ...-}-- ------------------------------------------------------------------------------- Asynchronous exceptions-- | When invoked inside 'mask', this function allows a masked-- asynchronous exception to be raised, if one exists.  It is-- equivalent to performing an interruptible operation (see-- #interruptible), but does not involve any actual blocking.---- When called outside 'mask', or inside 'uninterruptibleMask', this-- function has no effect.---- @since 4.4.0.0allowInterrupt::IO()allowInterrupt=interruptible$return(){- $async #AsynchronousExceptions# Asynchronous exceptions are so-called because they arise due toexternal influences, and can be raised at any point during execution.'StackOverflow' and 'HeapOverflow' are two examples ofsystem-generated asynchronous exceptions.The primary source of asynchronous exceptions, however, is'throwTo':>  throwTo :: ThreadId -> Exception -> IO ()'throwTo' (also 'Control.Concurrent.killThread') allows onerunning thread to raise an arbitrary exception in another thread.  Theexception 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 tooeasy to introduce race conditions by the over zealous use of'throwTo'.-}{- $block_handlerThere\'s an implied 'mask' around every exception handler in a callto one of the 'catch' family of functions.  This is because that iswhat you want most of the time - it eliminates a common race conditionin starting an exception handler, because there may be no exceptionhandler on the stack to handle another exception if one arrivesimmediately.  If asynchronous exceptions are masked on entering thehandler, though, we have time to install a new exception handlerbefore being interrupted.  If this weren\'t the default, one would haveto write something like>      mask $ \restore ->>           catch (restore (...))>                 (\e -> handler)If you need to unmask asynchronous exceptions again in the exceptionhandler, 'restore' can be used there too.Note that 'try' and friends /do not/ have a similar default, becausethere is no exception handler in this case.  Don't use 'try' forrecovering from an asynchronous exception.-}{- $interruptible #interruptible#Some operations are /interruptible/, which means that they can receiveasynchronous exceptions even in the scope of a 'mask'.  Any functionwhich may itself block is defined as interruptible; this includes'Control.Concurrent.MVar.takeMVar'(but not 'Control.Concurrent.MVar.tryTakeMVar'),and most operations which performsome I\/O with the outside world.  The reason for havinginterruptible operations is so that we can write things like>      mask $ \restore -> do>         a <- takeMVar m>         catch (restore (...))>               (\e -> ...)if the 'Control.Concurrent.MVar.takeMVar' was not interruptible,then this particularcombination could lead to deadlock, because the thread itself would beblocked in a state where it can\'t receive any asynchronous exceptions.With 'Control.Concurrent.MVar.takeMVar' interruptible, however, we can besafe in the knowledge that the thread can receive exceptions right upuntil the point when the 'Control.Concurrent.MVar.takeMVar' succeeds.Similar arguments apply for other interruptible operations like'System.IO.openFile'.It is useful to think of 'mask' not as a way to completely preventasynchronous exceptions, but as a way to switch from asynchronous modeto polling mode.  The main difficulty with asynchronousexceptions is that they normally can occur anywhere, but within a'mask' an asynchronous exception is only raised by operations that areinterruptible (or call other interruptible operations).  In many casesthese operations may themselves raise exceptions, such as I\/O errors,so the caller will usually be prepared to handle exceptions arising from theoperation anyway.  To perform an explicit poll for asynchronous exceptionsinside 'mask', use 'allowInterrupt'.Sometimes it is too onerous to handle exceptions in the middle of acritical piece of stateful code.  There are three ways to handle thiskind 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@ except for 'throwTo' * @tryTakeMVar@, @tryPutMVar@, @isEmptyMVar@ * @takeMVar@ if the @MVar@ is definitely full, and conversely @putMVar@ if the @MVar@ is definitely empty * @newEmptyMVar@, @newMVar@ * @forkIO@, @forkIOUnmasked@, @myThreadId@-}{- $catchallIt 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 existthen continue as if it contained \"\".  You might be tempted to justcatch all exceptions and return \"\" in the handler. However, this hasall sorts of undesirable consequences.  For example, if the userpresses control-C at just the right moment then the 'UserInterrupt'exception will be caught, and the program will continue running underthe belief that the file contains \"\".  Similarly, if another threadtries to kill the thread reading the file then the 'ThreadKilled'exception will be ignored.Instead, you should only catch exactly the exceptions that you reallywant. In this case, this would likely be more specific than even\"any IO exception\"; a permissions error would likely also want to behandled differently. Instead, you would probably want something like:> e <- tryJust (guard . isDoesNotExistError) (readFile f)> let str = either (const "") id eThere are occasions when you really do need to catch any sort ofexception. However, in most cases this is just so you can do somecleaning 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, butjust call the cleanup functions at the appropriate points.But sometimes you really do need to catch any exception, and actuallysee what the exception is. One example is at the very top-level of aprogram, you may wish to catch any exception, print it to a logfile orthe screen, and then exit gracefully. For these cases, you can use'catch' (or one of the other exception-catching functions) with the'SomeException' type.-}