summaryrefslogtreecommitdiff
path: root/libraries/base/Control/Exception.hs
Commit message (Collapse)AuthorAgeFilesLines
* Rename SomeExceptionWithLocation to SomeExceptionWithBacktraceSven Tennie2022-02-111-5/+5
|
* Add backtrace capturing and wrap SomeException with SomeExceptionWithLocationSven Tennie2022-02-111-0/+1
| | | | | | | | | | | | | | | | | | | | Replace raise# and raiseIO# with throw and throwIO to append backtraces. And add tests. The structure is now close to the proposal. Add pretty printing of backtraces. ------------------------- Metric Decrease: T19695 T9630 Metric Increase: MultiComponentModules MultiComponentModulesRecomp T13035 T9872d -------------------------
* Replace SomeException with SomeExceptionWithLocation (#18159)Sven Tennie2022-02-111-6/+5
| | | | | To keep backwards compatibility, for older GHC versions SomeExceptionWithLocation is only a synonym for SomeException.
* Fix ambiguous/out-of-scope Haddock identifiersAlec Theriault2018-08-211-8/+11
| | | | | | | | | | | | | | | | | This drastically cuts down on the number of Haddock warnings when making docs for `base`. Plus this means more actual links end up in the docs! Also fixed other small mostly markup issues in the documentation along the way. This is a docs-only change. Reviewers: hvr, bgamari, thomie Reviewed By: thomie Subscribers: thomie, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5055
* Fix minor typoIsmail2017-07-111-1/+1
|
* Overhaul of Compact Regions (#12455)Simon Marlow2016-12-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit makes various improvements and addresses some issues with Compact Regions (aka Compact Normal Forms). This was the most important thing I wanted to fix. Compaction previously prevented GC from running until it was complete, which would be a problem in a multicore setting. Now, we compact using a hand-written Cmm routine that can be interrupted at any point. When a GC is triggered during a sharing-enabled compaction, the GC has to traverse and update the hash table, so this hash table is now stored in the StgCompactNFData object. Previously, compaction consisted of a deepseq using the NFData class, followed by a traversal in C code to copy the data. This is now done in a single pass with hand-written Cmm (see rts/Compact.cmm). We no longer use the NFData instances, instead the Cmm routine evaluates components directly as it compacts. The new compaction is about 50% faster than the old one with no sharing, and a little faster on average with sharing (the cost of the hash table dominates when we're doing sharing). Static objects that don't (transitively) refer to any CAFs don't need to be copied into the compact region. In particular this means we often avoid copying Char values and small Int values, because these are static closures in the runtime. Each Compact# object can support a single compactAdd# operation at any given time, so the Data.Compact library now enforces mutual exclusion using an MVar stored in the Compact object. We now get exceptions rather than killing everything with a barf() when we encounter an object that cannot be compacted (a function, or a mutable object). We now also detect pinned objects, which can't be compacted either. The Data.Compact API has been refactored and cleaned up. A new compactSize operation returns the size (in bytes) of the compact object. Most of the documentation is in the Haddock docs for the compact library, which I've expanded and improved here. Various comments in the code have been improved, especially the main Note [Compact Normal Forms] in rts/sm/CNF.c. I've added a few tests, and expanded a few of the tests that were there. We now also run the tests with GHCi, and in a new test way that enables sanity checking (+RTS -DS). There's a benchmark in libraries/compact/tests/compact_bench.hs for measuring compaction speed and comparing sharing vs. no sharing. The field totalDataW in StgCompactNFData was unnecessary. Test Plan: * new unit tests * validate * tested manually that we can compact Data.Aeson data Reviewers: gcampax, bgamari, ezyang, austin, niteria, hvr, erikd Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D2751 GHC Trac Issues: #12455
* Typos in commentsGabor Greif2016-12-011-1/+1
|
* Add @since annotations to base instancesSeraphime Kirkovski2016-06-061-0/+1
| | | | | | | | | | | | | | | | | | Add @since annotations to instances in `base`. Test Plan: * ./validate # some commets shouldn't break the build * review the annotations for absurdities. Reviewers: ekmett, goldfire, RyanGlScott, austin, hvr, bgamari Reviewed By: RyanGlScott, hvr, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2277 GHC Trac Issues: #11767
* Associate ErrorCall pattern with ErrorCall typeHerbert Valerio Riedel2015-12-081-2/+1
| | | | | | | | | | | | | | | | | | | This way, import Control.Exception (ErrorCall(ErrorCall)) or import Control.Exception (ErrorCall(..)) work as expected, and import the `ErrorCall` compatibility pattern as well. When #5273 was implemented, it wasn't possible yet to associated patterns with their types (see #10653). Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1588
* Use IP based CallStack in error and undefinedEric Seidel2015-09-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch modifies `error`, `undefined`, and `assertError` to use implicit call-stacks to provide better error messages to users. There are a few knock-on effects: - `GHC.Classes.IP` is now wired-in so it can be used in the wired-in types for `error` and `undefined`. - `TysPrim.tyVarList` has been replaced with a new function `TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce subtle bugs when you need tyvars of different kinds. The naive ``` tv1 = head $ tyVarList kind1 tv2 = head $ tyVarList kind2 ``` would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions would be applied incorrectly, treating `tv1` and `tv2` as the same tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds and producing a single tyvar of each kind. - The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in ghc-prim. - The type `GHC.Exception.ErrorCall` has a new constructor `ErrorCallWithLocation` that takes two `String`s instead of one, the 2nd one being arbitrary metadata about the error (but usually the call-stack). A bi-directional pattern synonym `ErrorCall` continues to provide the old API. Updates Cabal, array, and haddock submodules. Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter, liyang, bgamari, thomie Differential Revision: https://phabricator.haskell.org/D861 GHC Trac Issues: #5273
* Don't allowInterrupt inside uninterruptibleMaskBen Gamari2015-07-301-3/+4
| | | | | | | | This fixes #9516. Differential Revision: https://phabricator.haskell.org/D181 Authored-by: Edsko de Vries <edsko@well-typed.com>
* Deferred type errors now throw TypeError (#10284)David Kraeutmann2015-07-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | Depends on D864. Previous behaviour was ErrorCall, which might mask issues in tests using -fdefer-type-errors Signed-off-by: David Kraeutmann <kane@kane.cx> Test Plan: Test whether the error thrown is indeed TypeError and not ErrorCall. Reviewers: hvr, nomeata, austin Reviewed By: nomeata, austin Subscribers: nomeata, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D866 GHC Trac Issues: #10284
* Convert `/Since: .../` to new `@since ...` syntaxHerbert Valerio Riedel2014-12-161-1/+1
| | | | | | Starting with Haddock 2.16 there's a new built-in support for since-annotations Note: This exposes a bug in the `@since` implementation (see e.g. `Data.Bits`)
* Per-thread allocation counters and limitsSimon Marlow2014-11-121-0/+1
| | | | | | | | This reverts commit f0fcc41d755876a1b02d1c7c79f57515059f6417. New changes: now works on 32-bit platforms too. I added some basic support for 64-bit subtraction and comparison operations to the x86 NCG.
* Refer to 'mask' instead of 'block' in Control.ExceptionThomas Miedema2014-09-251-4/+4
| | | | | | | | | | | | | | | | | Summary: More thorough version of a75383cdd46f7bb593639bc6d1628b068b78262a Test Plan: change of comments only [skip ci] Reviewers: austin, simonmar, ekmett Reviewed By: austin, ekmett Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D239
* Move `Maybe`-typedef into GHC.BaseHerbert Valerio Riedel2014-09-161-1/+0
| | | | | | | This is preparatory work for reintroducing SPECIALISEs that were lost in d94de87252d0fe2ae97341d186b03a2fbe136b04 Differential Revision: https://phabricator.haskell.org/D214
* Revert "Per-thread allocation counters and limits"Simon Marlow2014-05-041-1/+0
| | | | | | | | Problems were found on 32-bit platforms, I'll commit again when I have a fix. This reverts the following commits: 54b31f744848da872c7c6366dea840748e01b5cf b0534f78a73f972e279eed4447a5687bd6a8308e
* Per-thread allocation counters and limitsSimon Marlow2014-05-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | This tracks the amount of memory allocation by each thread in a counter stored in the TSO. Optionally, when the counter drops below zero (it counts down), the thread can be sent an asynchronous exception: AllocationLimitExceeded. When this happens, given a small additional limit so that it can handle the exception. See documentation in GHC.Conc for more details. Allocation limits are similar to timeouts, but - timeouts use real time, not CPU time. Allocation limits do not count anything while the thread is blocked or in foreign code. - timeouts don't re-trigger if the thread catches the exception, allocation limits do. - timeouts can catch non-allocating loops, if you use -fno-omit-yields. This doesn't work for allocation limits. I couldn't measure any impact on benchmarks with these changes, even for nofib/smp.
* Add Haddock `/Since: 4.4.0.0/` comments to symbolsHerbert Valerio Riedel2013-09-221-0/+2
| | | | | | | | | | This commit retroactively adds `/Since: 4.4.0.0/` annotations to symbols newly added/exposed in `base-4.4.0.0` (as shipped with GHC 7.2.1). See also 6368362f which adds the respective annotation for symbols newly added in `base-4.7.0.0` (that goes together with GHC 7.8.1). Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Constant-fold `__GLASGOW_HASKELL__` CPP conditionalsHerbert Valerio Riedel2013-09-171-10/+1
| | | | | | | | | | Now that HUGS and NHC specific code has been removed, this commit "folds" the now redundant `#if((n)def)`s containing `__GLASGOW_HASKELL__`. This renders `base` officially GHC only. This commit also removes redundant `{-# LANGUAGE CPP #-}`. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Remove Hugs98 specific codeHerbert Valerio Riedel2013-09-171-5/+1
| | | | | | | For rationale. see http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2349 Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* throwTo is interruptible.Edward Z. Yang2013-04-161-1/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
* Remove blocked (deprecated since 7.2)Ian Lynagh2013-02-191-4/+0
|
* Remove block and unblock (deprecated since GHC 7.0)Ian Lynagh2013-02-191-2/+0
|
* Remove nhc98-specific files and contentIan Lynagh2013-02-151-9/+0
|
* Make a class for asynchronous exceptions in the exception hierarchySimon Marlow2012-12-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | Right now, we only have data AsyncException = StackOverflow | HeapOverflow | ThreadKilled | ... so it is not possible to add another async exception. For instance, the Timeout exception in System.Timeout should really be an async exception. This patch adds a superclass for all async exceptions: data SomeAsyncException = forall e . Exception e => SomeAsyncException e deriving Typeable and makes the existing AsyncException and Timeout children of SomeAsyncException in the hierarchy.
* Fix Haddock formatting in Control.ExceptionIustin Pop2012-11-081-0/+7
| | | | | | | | This fixes Haddock formatting in the second list in the section "Interruptible operations": haddock lists items should be separated by blank lines. Signed-off-by: Iustin Pop <iusty@k1024.org>
* Add Functor instance for Handler (#7047)Simon Marlow2012-07-041-0/+3
|
* SafeHaskell: Added SafeHaskell to baseDavid Terei2011-06-181-0/+1
|
* Add allowInterrupt :: IO () (#4810)Simon Marlow2010-12-221-4/+17
| | | | | | | | | | | | docs: -- | 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 -- #interruptible#), but does not involve any actual blocking. -- -- When called outside 'mask', or inside 'uninterruptibleMask', this -- function has no effect.
* Use explicit language extensions & remove extension fields from base.cabalsimonpj@microsoft.com2011-01-281-1/+1
| | | | | | | | | | Add explicit {-# LANGUAGE xxx #-} pragmas to each module, that say what extensions that module uses. This makes it clearer where different extensions are used in the (large, variagated) base package. Now base.cabal doesn't need any extensions field Thanks to Bas van Dijk for doing all the work.
* extend the documentation about interruptible operationsSimon Marlow2010-12-011-1/+44
|
* doc fix: don't refer to unblock.Simon Marlow2010-11-081-1/+1
|
* Refer to 'mask' instead of 'block' in documentation of Control.ExceptionBas van Dijk2010-10-161-4/+4
|
* Allow nhc98 to cope with recent changes to Control.Exception.Malcolm.Wallace@me.com2010-07-101-0/+2
|
* New asynchronous exception control API (base parts)Simon Marlow2010-07-081-10/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed on the libraries/haskell-cafe mailing lists http://www.haskell.org/pipermail/libraries/2010-April/013420.html This is a replacement for block/unblock in the asychronous exceptions API to fix a problem whereby a function could unblock asynchronous exceptions even if called within a blocked context. The new terminology is "mask" rather than "block" (to avoid confusion due to overloaded meanings of the latter). The following is the new API; the old API is deprecated but still available for the time being. Control.Exception ----------------- mask :: ((forall a. IO a -> IO a) -> IO b) -> IO b mask_ :: IO a -> IO a uninterruptibleMask :: ((forall a. IO a -> IO a) -> IO b) -> IO b uninterruptibleMask_ :: IO a -> IO getMaskingState :: IO MaskingState data MaskingState = Unmasked | MaskedInterruptible | MaskedUninterruptible Control.Concurrent ------------------ forkIOUnmasked :: IO () -> IO ThreadId
* Address #3310Simon Marlow2009-08-301-2/+2
| | | | | | | | | | | | | | - Rename BlockedOnDeadMVar -> BlockedIndefinitelyOnMVar - Rename BlockedIndefinitely -> BlockedIndefinitelyOnSTM - instance Show BlockedIndefinitelyOnMVar is now "blocked indefinitely in an MVar operation" - instance Show BlockedIndefinitelyOnSTM is now "blocked indefinitely in an STM transaction" clients using Control.OldException will be unaffected (the new exceptions are mapped to the old names). However, for base4-compat we'll need to make a version of catch/try that does a similar mapping.
* Remove unused imports from basesimonpj@microsoft.com2009-07-061-1/+1
| | | | | These unused imports are detected by the new unused-import code
* Rewrite of the IO library, including Unicode supportSimon Marlow2009-06-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Highlights: * Unicode support for Handle I/O: ** Automatic encoding and decoding using a per-Handle encoding. ** The encoding defaults to the locale encoding (only on Unix so far, perhaps Windows later). ** Built-in UTF-8, UTF-16 (BE/LE), and UTF-32 (BE/LE) codecs. ** iconv-based codec for other encodings on Unix * Modularity: the low-level IO interface is exposed as a type class (GHC.IO.IODevice) so you can build your own low-level IO providers and make Handles from them. * Newline translation: instead of being Windows-specific wired-in magic, the translation from \r\n -> \n and back again is available on all platforms and is configurable for reading/writing independently. Unicode-aware Handles ~~~~~~~~~~~~~~~~~~~~~ This is a significant restructuring of the Handle implementation with the primary goal of supporting Unicode character encodings. The only change to the existing behaviour is that by default, text IO is done in the prevailing locale encoding of the system (except on Windows [1]). Handles created by openBinaryFile use the Latin-1 encoding, as do Handles placed in binary mode using hSetBinaryMode. We provide a way to change the encoding for an existing Handle: GHC.IO.Handle.hSetEncoding :: Handle -> TextEncoding -> IO () and various encodings (from GHC.IO.Encoding): latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, localeEncoding, and a way to lookup other encodings: GHC.IO.Encoding.mkTextEncoding :: String -> IO TextEncoding (it's system-dependent whether the requested encoding will be available). We may want to export these from somewhere more permanent; that's a topic for a future library proposal. Thanks to suggestions from Duncan Coutts, it's possible to call hSetEncoding even on buffered read Handles, and the right thing happens. So we can read from text streams that include multiple encodings, such as an HTTP response or email message, without having to turn buffering off (though there is a penalty for switching encodings on a buffered Handle, as the IO system has to do some re-decoding to figure out where it should start reading from again). If there is a decoding error, it is reported when an attempt is made to read the offending character from the Handle, as you would expect. Performance varies. For "hGetContents >>= putStr" I found the new library was faster on my x86_64 machine, but slower on an x86. On the whole I'd expect things to be a bit slower due to the extra decoding/encoding, but probabaly not noticeably. If performance is critical for your app, then you should be using bytestring and text anyway. [1] Note: locale encoding is not currently implemented on Windows due to the built-in Win32 APIs for encoding/decoding not being sufficient for our purposes. Ask me for details. Offers of help gratefully accepted. Newline Translation ~~~~~~~~~~~~~~~~~~~ In the old IO library, text-mode Handles on Windows had automatic translation from \r\n -> \n on input, and the opposite on output. It was implemented using the underlying CRT functions, which meant that there were certain odd restrictions, such as read/write text handles needing to be unbuffered, and seeking not working at all on text Handles. In the rewrite, newline translation is now implemented in the upper layers, as it needs to be since we have to perform Unicode decoding before newline translation. This means that it is now available on all platforms, which can be quite handy for writing portable code. For now, I have left the behaviour as it was, namely \r\n -> \n on Windows, and no translation on Unix. However, another reasonable default (similar to what Python does) would be to do \r\n -> \n on input, and convert to the platform-native representation (either \r\n or \n) on output. This is called universalNewlineMode (below). The API is as follows. (available from GHC.IO.Handle for now, again this is something we will probably want to try to get into System.IO at some point): -- | The representation of a newline in the external file or stream. data Newline = LF -- ^ "\n" | CRLF -- ^ "\r\n" deriving Eq -- | Specifies the translation, if any, of newline characters between -- internal Strings and the external file or stream. Haskell Strings -- are assumed to represent newlines with the '\n' character; the -- newline mode specifies how to translate '\n' on output, and what to -- translate into '\n' on input. data NewlineMode = NewlineMode { inputNL :: Newline, -- ^ the representation of newlines on input outputNL :: Newline -- ^ the representation of newlines on output } deriving Eq -- | The native newline representation for the current platform nativeNewline :: Newline -- | Map "\r\n" into "\n" on input, and "\n" to the native newline -- represetnation on output. This mode can be used on any platform, and -- works with text files using any newline convention. The downside is -- that @readFile a >>= writeFile b@ might yield a different file. universalNewlineMode :: NewlineMode universalNewlineMode = NewlineMode { inputNL = CRLF, outputNL = nativeNewline } -- | Use the native newline representation on both input and output nativeNewlineMode :: NewlineMode nativeNewlineMode = NewlineMode { inputNL = nativeNewline, outputNL = nativeNewline } -- | Do no newline translation at all. noNewlineTranslation :: NewlineMode noNewlineTranslation = NewlineMode { inputNL = LF, outputNL = LF } -- | Change the newline translation mode on the Handle. hSetNewlineMode :: Handle -> NewlineMode -> IO () IO Devices ~~~~~~~~~~ The major change here is that the implementation of the Handle operations is separated from the underlying IO device, using type classes. File descriptors are just one IO provider; I have also implemented memory-mapped files (good for random-access read/write) and a Handle that pipes output to a Chan (useful for testing code that writes to a Handle). New kinds of Handle can be implemented outside the base package, for instance someone could write bytestringToHandle. A Handle is made using mkFileHandle: -- | makes a new 'Handle' mkFileHandle :: (IODevice dev, BufferedIO dev, Typeable dev) => dev -- ^ the underlying IO device, which must support -- 'IODevice', 'BufferedIO' and 'Typeable' -> FilePath -- ^ a string describing the 'Handle', e.g. the file -- path for a file. Used in error messages. -> IOMode -- ^ The mode in which the 'Handle' is to be used -> Maybe TextEncoding -- ^ text encoding to use, if any -> NewlineMode -- ^ newline translation mode -> IO Handle This also means that someone can write a completely new IO implementation on Windows based on native Win32 HANDLEs, and distribute it as a separate package (I really hope somebody does this!). This restructuring isn't as radical as previous designs. I haven't made any attempt to make a separate binary I/O layer, for example (although hGetBuf/hPutBuf do bypass the text encoding and newline translation). The main goal here was to get Unicode support in, and to allow others to experiment with making new kinds of Handle. We could split up the layers further later. API changes and Module structure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NB. GHC.IOBase and GHC.Handle are now DEPRECATED (they are still present, but are just re-exporting things from other modules now). For 6.12 we'll want to bump base to version 5 and add a base4-compat. For now I'm using #if __GLASGOW_HASKEL__ >= 611 to avoid deprecated warnings. I split modules into smaller parts in many places. For example, we now have GHC.IORef, GHC.MVar and GHC.IOArray containing the implementations of IORef, MVar and IOArray respectively. This was necessary for untangling dependencies, but it also makes things easier to follow. The new module structurue for the IO-relatied parts of the base package is: GHC.IO Implementation of the IO monad; unsafe*; throw/catch GHC.IO.IOMode The IOMode type GHC.IO.Buffer Buffers and operations on them GHC.IO.Device The IODevice and RawIO classes. GHC.IO.BufferedIO The BufferedIO class. GHC.IO.FD The FD type, with instances of IODevice, RawIO and BufferedIO. GHC.IO.Exception IO-related Exceptions GHC.IO.Encoding The TextEncoding type; built-in TextEncodings; mkTextEncoding GHC.IO.Encoding.Types GHC.IO.Encoding.Iconv GHC.IO.Encoding.Latin1 GHC.IO.Encoding.UTF8 GHC.IO.Encoding.UTF16 GHC.IO.Encoding.UTF32 Implementation internals for GHC.IO.Encoding GHC.IO.Handle The main API for GHC's Handle implementation, provides all the Handle operations + mkFileHandle + hSetEncoding. GHC.IO.Handle.Types GHC.IO.Handle.Internals GHC.IO.Handle.Text Implementation of Handles and operations. GHC.IO.Handle.FD Parts of the Handle API implemented by file-descriptors: openFile, stdin, stdout, stderr, fdToHandle etc.
* add some rules of thumb for catching exceptions, restructure the docs a bitSimon Marlow2009-02-051-20/+56
|
* Update the Exception docsIan Lynagh2009-01-311-22/+93
|
* No reason for Handler and catches to exclude nhc98.Malcolm.Wallace@cs.york.ac.uk2008-08-131-9/+5
|
* Must import ExitCode for its instance to be re-exported.Malcolm.Wallace@cs.york.ac.uk2008-08-131-0/+7
| | | | | The Cabal library depends on "instance Exception ExitCode", and expects to import it from Control.Exception, not Control.Exception.Base.
* non-GHC: hide Prelude.catchRoss Paterson2008-08-121-0/+2
|
* split most of Control.Exception into new Control.Exception.BaseRoss Paterson2008-08-121-436/+13
| | | | | | | | | | | | | Move everything but catches/Handler into a new internal module. This was needed to get the new exceptions working with Hugs, because Hugs has the constraint that all Haskell 98 library modules, and everything they include, must be Haskell 98. This also involves a different representation of SomeException for Hugs, so that type is exported opaquely for Hugs. Then Control.Exception.Base is Haskell 98 as far as Hugs is concerned, but Control.Exception needs the extensions turned on. Control.Exception re-exports everything from Control.Exception.Base except the functions used by the GHC runtime.
* Control.Exception doesn't need to export assertErrorIan Lynagh2008-08-041-1/+0
|
* Generalise the type of mapException; pointed out by Isaac DupreeIan Lynagh2008-08-041-1/+1
|
* make ExitCode an instance of Exception for nhc98Malcolm.Wallace@cs.york.ac.uk2008-08-051-0/+4
|
* Fix nhc98 code variations to use the extensible exception API.Malcolm.Wallace@cs.york.ac.uk2008-08-041-11/+68
| | | | | There is still only one real exception type in nhc98, so it is not truly extensible. But this is enough to get the base package building again.
* Remove the duplicate definition of throwTo in Control.ExceptionIan Lynagh2008-08-031-8/+1
| | | | It now imports GHC.Conc, so it is no longer necessary
View Lorry Controller Status