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 suggestion a lot, however it seems a bit more invasive. If we want to do that work, we could also restructure the wired-in exceptions so they're more hierarchical. There are some top-level exceptions we can get by type, such as ArithException, but sadly many interesting and useful exceptions are lumped together under IOException. On Wed, Jul 10, 2013 at 4:29 PM, Ertugrul Söylemez <e...@ertes.de> wrote: > 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 > > right approach to take here? > > I think there is no one right approach. However, if you add such a > function to the exception library, it really belongs into the Exception > type class with the following type: > > shouldBeCaught :: (Exception e) => e -> Bool > > However, a better approach is to have exception tags. In most cases you > don't want to catch killThread's or timeout's exception, but you do want > to catch all error exceptions: > > data Tag = Error | Abort | TryAgain | {- ... -} | Other String > deriving (Data, Eq, Ord, Read, Show, Typeable) > > instance IsString Tag where > fromString t = Other t > > This could then manifest in the following two functions in the Exception > type class: > > hasTag :: (Exception e) => Tag -> e -> Bool > tagsOf :: (Exception e) => e -> [Tag] > > Then exception catchers (functions that risk swallowing important > exceptions) could filter by type and tag. > > > Greets, > Ertugrul > > -- > Not to be or to be and (not to be or to be and (not to be or to be and > (not to be or to be and ... that is the list monad. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe