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.
I wrote up the blog
On Thu, Jul 11, 2013 at 3:44 AM, John Lato jwl...@gmail.com wrote:
Hi Michael,
I don't think those are particularly niche cases, but I still think this
is a bad approach to solving the problem. My reply to Erik explicitly
covers the worker thread case, and for running arbitrary user code
On Thu, Jul 11, 2013 at 10:56 AM, Michael Snoyman mich...@snoyman.com 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.
On Thu, Jul 11, 2013 at 6:07 PM, Felipe Almeida Lessa
felipe.le...@gmail.com wrote:
On Thu, Jul 11, 2013 at 10:56 AM, Michael Snoyman mich...@snoyman.com
wrote:
The only
approach that handles the situation correctly is John's separate thread
approach (tryAll3).
I think you meant
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
There's a pattern that arises fairly often: catching every exception thrown
by code. The naive approach is to do something like:
result - try someCode
case result of
Left (e :: SomeException) - putStrLn $ It failed: ++ show e
Right realValue - useRealValue
This seems
Michael Snoyman mich...@snoyman.com wrote:
shouldBeCaught :: SomeException - Bool
One first stab at such a function would be to return `False` for
AsyncException and Timeout, and `True` for everything else, but I'm
not convinced that this is sufficient. Are there any thoughts on the
I think 'shouldBeCaught' is more often than not the wrong thing. A
whitelist of exceptions you're prepared to handle makes much more sense
than excluding certain operations. Some common whitelists, e.g. filesystem
exceptions or network exceptions, might be useful to have.
I like Ertugrul's
Hi Michael,
We do this as well. In addition to AsyncException, we ignore
BlockedIndefinitelyOnSTM, BlockedIndefinitelyOnMVar and Deadlock. I'm
not sure you can ignore Timeout, since the type is not exported from
System.Timeout. I'm not sure how to classify these, though. They are
in some sense
On Wed, Jul 10, 2013 at 10:39 AM, John Lato jwl...@gmail.com wrote:
I think 'shouldBeCaught' is more often than not the wrong thing. A
whitelist of exceptions you're prepared to handle makes much more sense than
excluding certain operations. Some common whitelists, e.g. filesystem
exceptions
Don´t tried it and probably it does not even compile, but a possibility
could be along these lines:
catchExcept excepts handle e= do
if not . null $ filter ( \(SomeException e') - typeOf e= typeOf e')
excepts
then throw e
else handle e
use:
u= undefined
excluded=
On Wed, Jul 10, 2013 at 5:02 PM, Erik Hesselink hessel...@gmail.com wrote:
On Wed, Jul 10, 2013 at 10:39 AM, John Lato jwl...@gmail.com wrote:
I think 'shouldBeCaught' is more often than not the wrong thing. A
whitelist of exceptions you're prepared to handle makes much more sense
than
On Wed, Jul 10, 2013 at 1:01 PM, John Lato jwl...@gmail.com wrote:
On Wed, Jul 10, 2013 at 5:02 PM, Erik Hesselink hessel...@gmail.comwrote:
On Wed, Jul 10, 2013 at 10:39 AM, John Lato jwl...@gmail.com wrote:
I think 'shouldBeCaught' is more often than not the wrong thing. A
whitelist of
I think that new SomeAsyncException type in base is supposed to make
it possible to ignore all asynchronous exceptions.
https://github.com/ghc/packages-base/blob/master/GHC/IO/Exception.hs#L113
On Wed, 10 Jul 2013 09:28:12 +0300 Michael Snoyman
mich...@snoyman.com wrote:
There's a pattern that
Michael Snoyman mich...@snoyman.com wrote:
Any thoughts on this? I'm not sure exactly what would be the right
method to add to the Exception typeclass, but if we can come to
consensus on that and there are no major objections to my separate
package proposal, I think this would be something
Hi Michael,
I don't think those are particularly niche cases, but I still think this is
a bad approach to solving the problem. My reply to Erik explicitly covers
the worker thread case, and for running arbitrary user code (as in your top
line) it's even simpler: just fork a new thread for the
16 matches
Mail list logo
