[Haskell-cafe] Absolutely confused with error/exception handling

[Saurabh Nanda]

> 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 at gmail.com> wrote:

>
> On Thu, Dec 15, 2016 at 10:30 PM, Saurabh Nanda <saurabhnanda at 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 at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20161216/e75ab786/attachment.html>