> Consider the case of StateT s IO: your exception handler can get an `s` known when the `catch` is evaluated, but can never know the *current* value of the `s` when the exception is thrown --- exceptions do not know how to carry state around like that, and in the most general case can't know how. There are various frameworks that attempt to add this kind of functionality, such as MonadCatch and MonadBaseControl; but it's fairly tricky even at the best of times.

Apologies, but I couldn't understand the example. In an exception where it's not even possible to know the stack trace easily,  I don't expect to know the state of the computation. It's an exception -- it is alright if it doesn't have the state. But at least allow me to catch the exception in MonadIO. 

And this brings me to my original question. What do I need to do to catch an exception in spock's ActionT? I thought I didn't understand something earlier. But now it seems that I have hit a hairy part of Haskell. 

--Saurabh. 


On 16 Dec 2016 9:14 am, "Brandon Allbery" <allbery.b@gmail.com> wrote:

On Thu, Dec 15, 2016 at 10:30 PM, Saurabh Nanda <saurabhnanda@gmail.com> wrote:

Any reason for "error" and "catch" to be in different packages? Or, why isn't "catch" in prelude?

"catch" needs a action in IO. What if I have an action in MonadIO?

A version of `catch` used to be in Prelude, but it *only* worked with the IOException subtype; the one in Control.Exception works for all exception types. Rather than propagate the confusion between them, or risk breaking code in weird ways (the one in Prelude was restricted in part because the exception system was redesigned to be extensible, and the Prelude version didn't handle the way the new exception types work), it was simply removed. The Prelude one was something of an oddity even before extensible exceptions and mostly confused new Haskellers, so there didn't seem to be much reason to keep it around.

MonadIO is going to be hard. It's not a type but a typeclass for things that can perform operations in IO; but this is not (and can't be, if you think about it) bidirectional. Consider the case of StateT s IO: your exception handler can get an `s` known when the `catch` is evaluated, but can never know the *current* value of the `s` when the exception is thrown --- exceptions do not know how to carry state around like that, and in the most general case can't know how. There are various frameworks that attempt to add this kind of functionality, such as MonadCatch and MonadBaseControl; but it's fairly tricky even at the best of times.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net