jcristovao/enclosed-exceptions

Catching all synchronous exceptions in Haskell, while re-throwing all asynchronous exceptions

enclosed-exceptions's Issues

tryAny catches StackOverflow

Steps to reproduce:

import           Control.Exception.Enclosed

main = do
  r <- tryAny (print $ foldl (+) 0 [1 .. 100000 :: Int])
  print r

$ ghci Main.hs +RTS -K1K
*Main> main 
Left stack overflow

tryDeep, catchDeep

These aren't needed as frequently, but I did find a use today and they are probably good for completeness.

  tryDeep :: (Exception e, NFData a, MonadBaseControl IO m)
          => m a
          -> m (Either e a)
  tryDeep m = try $ do
      x <- m
      liftBase $ evaluate $!! x

  catchDeep :: (Exception e, NFData a, MonadBaseControl IO m) => m a -> (e -> m a) -> m a
  catchDeep action onE = tryDeep action >>= either onE return

Unreliable test suites

This is a bug I introduced, just filing an issue since I may not have a moment to fix it immediately.

The test suite uses threadDelay to pass control between two difference threads of execution. This is not reliable, as threadDelay only gives a minimum delay time, not a maximum. When the system is under high load, this method can fail. We should instead use much more explicit control passing, such as via MVars.

Build fails with GHC 7.10 and 8.0

See https://travis-ci.org/mightybyte/enclosed-exceptions for details.

Test suite hangs with ghc 8.4 (apparently due to hspec-2.5.0)

The last thing printed is:

Control.Exception.Enclosed
  catchAny
    catches exceptions thrown from the inside
    doesn't catch exceptions thrown from the outside
    doesn't catch exceptions lazily thrown in its pure result
  catchDeep
    catches exceptions thrown from the inside
    catches exceptions thrown from the outside
    catches exceptions lazily thrown in its pure result
  tryAny
    catches exceptions thrown from the inside
    doesn't catch exceptions thrown from the outside
    doesn't catch exceptions lazily thrown in its pure result

The next test is:

enclosed-exceptions/test/main.hs

Line 85 in ba1b356

it "isn't fooled by BlockedIndefinitelyOnMVar" $ do

which suggests to me that something is going on with the "blocked indefinitely" behavior. Possibly a GHC regression?

Cleanup code doesn't get run after a `tryAny` of Snap's `httpServe`

This works fine.

        e <- try $ httpServe conf $ site :: IO (Either SomeException ())
        errorM "AdServer.Main.main" ("Got error while serving: " ++ show e)
        cleanup' cleanup

This doesn't run our cleanup code.

        e <- tryAny $ httpServe conf $ site
        errorM "AdServer.Main.main" ("Got error while serving: " ++ show e)
        cleanup' cleanup

I'm a bit flabbergasted as to why a lifted try would cause different behavior here, any ideas?

Repro:

Ctrl-C while blocking on a Snap server in GHCi

Good code runs our cleanup process, output like this:

^C
Shutting down...
Got error while serving: Right ()
Running Snap-provided cleanup function
Shutting down services
Killing the following services: Services {tableUpdate = Just ThreadId 574, stateServer = Just ThreadId 575, ekgServices = Nothing}
Removing logger handlers

Bad code shuts the Snap server down, but none of our secondary services get shut down and none of the logging associated with the cleanup runs. Output like this:

Listening on http://0.0.0.0:8000/
^CInterrupted.
Prelude>
Shutting down...

Prelude>

Only Snap's signal handling is getting run.

What did I do wrong?