<div dir="ltr">When I implemented this stuff yesterday, I included `Deep` variants for each function which used NFData. I'm debating whether I think the right recommendation is to, by default, use the `async`/NFData versions of catch, handle, and try, or to have them as separate functions.<div>
<br></div><div>I wrote up the blog post, both on the Yesod blog[1] and School of Haskell[2]. The latter's a bit easier to use since it includes active code snippets.</div><div><br></div><div>[1] <a href="http://www.yesodweb.com/blog/2013/07/catching-all-exceptions">http://www.yesodweb.com/blog/2013/07/catching-all-exceptions</a></div>
<div>[2] <a href="https://www.fpcomplete.com/user/snoyberg/general-haskell/exceptions/catching-all-exceptions">https://www.fpcomplete.com/user/snoyberg/general-haskell/exceptions/catching-all-exceptions</a></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 4:03 AM, John Lato <span dir="ltr"><<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I agree that how the exception was thrown is more interesting than the type. I feel like there should be a way to express the necessary information via the type system, but I'm not convinced it's easy (or even possible).<div>
<br></div><div>Another issue to be aware of is that exceptions can be thrown from pure code, so if you don't fully evaluate your return value an exception can be thrown later, outside the catch block. In practice this usually means an NFData constraint, or some other constraint for which you can guarantee evaluation.</div>
<div><br></div><div>In the past I've been pretty vocal about my opposition to exceptions. It's still my opinion that they do not make it easy to reason about exceptional conditions. Regardless, as Haskell has them and uses them, I'd like to see improvements if possible. So if anyone is exploring the design space, I'd be willing to participate. </div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 12:57 AM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 11, 2013 at 6:07 PM, Felipe Almeida Lessa <span dir="ltr"><<a href="mailto:felipe.lessa@gmail.com" target="_blank">felipe.lessa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Thu, Jul 11, 2013 at 10:56 AM, Michael Snoyman <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>> wrote:<br>
> The only<br>
> approach that handles the situation correctly is John's separate thread<br>
> approach (tryAll3).<br>
<br>
</div>I think you meant "tryAll2" here. Got me confused for some time =).<br>
<br>
Cheers,<br>
<br>
--<br>
Felipe.<br>
</blockquote></div><br></div></div></div><div class="gmail_extra">Doh, yes, I did, thanks for the clarification.</div><div class="gmail_extra"><br></div><div class="gmail_extra">After playing around with this a bit, I was able to get an implementation of try, catch, and handle which work for any non-async exception, in monad transformers which are instances of MonadBaseControl (from monad-control). I'll try to write up my thoughts in something more coherent, likely a blog post.</div>
<span><font color="#888888">
<div class="gmail_extra"><br></div><div class="gmail_extra">Michael</div></font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>