
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).
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.
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.
On Fri, Jul 12, 2013 at 12:57 AM, Michael Snoyman
On Thu, Jul 11, 2013 at 6:07 PM, Felipe Almeida Lessa < felipe.lessa@gmail.com> wrote:
On Thu, Jul 11, 2013 at 10:56 AM, Michael Snoyman
wrote: The only approach that handles the situation correctly is John's separate thread approach (tryAll3).
I think you meant "tryAll2" here. Got me confused for some time =).
Cheers,
-- Felipe.
Doh, yes, I did, thanks for the clarification.
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.
Michael