bracket

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

Bracket wraps the release action with mask, which is sufficient to ensure that the release action executes to completion when it does not invoke any interruptible actions, even in the presence of asynchronous exceptions. For example, hClose is uninterruptible when it is not racing other uses of the handle. Similarly, closing a socket (from "network" package) is also uninterruptible under similar conditions. An example of an interruptible action is killThread. Completion of interruptible release actions can be ensured by wrapping them in uninterruptibleMask_, but this risks making the program non-responsive to Control-C, or timeouts. Another option is to run the release action asynchronously in its own thread:

void $ uninterruptibleMask_ $ forkIO $ do { ... }

The resource will be released as soon as possible, but the thread that invoked bracket will not block in an uninterruptible state.

Generalized abstracted pattern of safe resource acquisition and release in the face of errors. The first action "acquires" some value, which is "released" by the second action at the end. The third action "uses" the value and its result is the result of the bracket. If an error is thrown during the use, the release still happens before the error is rethrown. Note that this is essentially a type-specialized version of generalBracket. This function has a more common signature (matching the signature from Control.Exception), and is often more convenient to use. By contrast, generalBracket is more expressive, allowing us to implement other functions like bracketOnError.

Allocate and clean up a resource safely. For more information on motivation and usage of this function, see base's bracket. This function has two differences from the one in base. The first, and more obvious, is that it works on any MonadUnliftIO instance, not just IO. The more subtle difference is that this function will use uninterruptible masking for its cleanup handler. This is a subtle distinction, but at a high level, means that resource cleanup has more guarantees to complete. This comes at the cost that an incorrectly written cleanup function cannot be interrupted. For more information, please see https://github.com/fpco/safe-exceptions/issues/3.

Async safe version of bracket

Generalized version of bracket. Note:

• When the "acquire" or "release" computations throw exceptions any monadic side effects in m will be discarded.
• When the "in-between" computation throws an exception any monadic side effects in m produced by that computation will be discarded but the side effects of the "acquire" or "release" computations will be retained.
• Also, any monadic side effects in m of the "release" computation will be discarded; it is run only for its side effects in IO.

Note that when your acquire and release computations are of type IO it will be more efficient to write:

liftBaseOp (bracket acquire release)

Allocate a resource, use it, and clean it up afterwards.

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

Bracket wraps the release action with mask, which is sufficient to ensure that the release action executes to completion when it does not invoke any interruptible actions, even in the presence of asynchronous exceptions. For example, hClose is uninterruptible when it is not racing other uses of the handle. Similarly, closing a socket (from "network" package) is also uninterruptible under similar conditions. An example of an interruptible action is killThread. Completion of interruptible release actions can be ensured by wrapping them in in uninterruptibleMask_, but this risks making the program non-responsive to Control-C, or timeouts. Another option is to run the release action asynchronously in its own thread:

void $ uninterruptibleMask_ $ forkIO $ do { ... }

The resource will be released as soon as possible, but the thread that invoked bracket will not block in an uninterruptible state.

Analogous to bracket from Control.Monad.Catch, except this also protects against premature termination

Parse a bracketed item, discarding the brackets. If everything matches except the closing bracket, the whole parse fails soft, which can give less-than-satisfying error messages. If you want better error messages, try calling with e.g. bracket open (commit close) item

Generates one or other of '[' and ']'.

Deprecated: Use Control.Monad.Catch.bracket instead

Run the alloc action IO b with async exceptions disabled but keeping blocking operations interruptible (see mask). Use the output b of the IO action as input to the function b -> Stream m a to generate an output stream. b is usually a resource under the IO monad, e.g. a file handle, that requires a cleanup after use. The cleanup action b -> m c, runs whenever (1) the stream ends normally, (2) due to a sync or async exception or, (3) if it gets garbage collected after a partial lazy evaluation. The exception is not caught, it is rethrown. bracket only guarantees that the cleanup action runs, and it runs with async exceptions enabled. The action must ensure that it can successfully cleanup the resource in the face of sync or async exceptions. When the stream ends normally or on a sync exception, cleanup action runs immediately in the current thread context, whereas in other cases it runs in the GC context, therefore, cleanup may be delayed until the GC gets to run. See also: bracket_ Inhibits stream fusion

Run the alloc action m b with async exceptions disabled but keeping blocking operations interruptible (see mask). Use the output b as input to b -> t m a to generate an output stream. b is usually a resource under the state of monad m, e.g. a file handle, that requires a cleanup after use. The cleanup action b -> m c, runs whenever the stream ends normally, due to a sync or async exception or if it gets garbage collected after a partial lazy evaluation. bracket only guarantees that the cleanup action runs, and it runs with async exceptions enabled. The action must ensure that it can successfully cleanup the resource in the face of sync or async exceptions. When the stream ends normally or on a sync exception, cleanup action runs immediately in the current thread context, whereas in other cases it runs in the GC context, therefore, cleanup may be delayed until the GC gets to run. See also: bracket_ Inhibits stream fusion

Run the alloc action a -> m c with async exceptions disabled but keeping blocking operations interruptible (see mask). Use the output c as input to Unfold m c b to generate an output stream. c is usually a resource under the state of monad m, e.g. a file handle, that requires a cleanup after use. The cleanup action c -> m d, runs whenever the stream ends normally, due to a sync or async exception or if it gets garbage collected after a partial lazy evaluation. bracket only guarantees that the cleanup action runs, and it runs with async exceptions enabled. The action must ensure that it can successfully cleanup the resource in the face of sync or async exceptions. When the stream ends normally or on a sync exception, cleanup action runs immediately in the current thread context, whereas in other cases it runs in the GC context, therefore, cleanup may be delayed until the GC gets to run. See also: bracket_, gbracket Inhibits stream fusion Pre-release

Lifted bracket.

Async safe version of bracket

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

Allocate a resource, use it, and clean it up afterwards.

Acquire a resource, use it, then release it back. The bracket pattern is common in Haskell for getting a resource ρ needed for a computation, preforming that computation, then returning the resource back to the system. Common examples are when making database connections and doing file or network operations, where you need to make sure you "close" the connection afterward before continuing the program so that scare resources like file handles are released. Typically you have an open and close action that return and take a resource respectively, so you can use those directly, and use a lambda in the third action to actally get at the resource and do something with it when you need it:

bracket
(openConnection)
(closeConnection)
(c -> do
this
thatAndNow
theOtherThingThatNeeds c
)

Note that bracket does not catch the exception if one is thrown! The finalizer will run, but then the exception will continue to propogate its way out of your program's call stack. Note also that the result of the cleanup action γ is ignored (it can be () or anythign else; it will be discarded).

Generalized version of bracket. Note, any monadic side effects in m of the "release" computation will be discarded; it is run only for its side effects in IO.