#8006: Asynchronous exception rethrown synchronously inside runStmt ---------------------------------+------------------------------------------ Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): Ok, well, before thinking about workarounds, let's just check that something closer to ideal is not possible. Here is a tiny example {{{ let x = unsafePerformIO $ do { let v = expensive 100 ; printToFile "logfile" ("Computed v" ++ show v) ; return v } }}} Here I am writing to a log-file as an example of the kind of benign side effect that should be ok in `unsafePerformIO`. So what should happen if an asynch exn is caught inside `printToFile` some I/O stuff is restored, and the exception is re-thrown? I would have that this principle should hold: * exactly the same thing should happen as would have happened if the exception was delivered when we ''were not'' inside any catch-blocks in `printToFile`. Namely, freeze and resume. I'd be inclined to resume just before the `throwTo`. So that might (just) cause the log file to be written to twice, but it's supposed be a benign side effect. It's a good point though. I wonder what the semantics says? Adding a new kind of catch does not seem like the right solution. `printToFile` might really really want to restore some invariants before aborting; if it can't catch async exns, it couldn't do so. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/8006#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler