Re: Discussion: add more idiomatic versions of catchJust and/or handleJust

I expect it'd be more common to use something like catchMaybe m $ \e -> guard (isEOFException e) >> return "" catchJust only makes sense if you not only need the same set of exceptions, but also the same non-trivial calculation based on the exception, for multiple handlers. A hypothetical catchOnly taking a Boolean predicate would make more sense for the case you describe. On Jul 14, 2016 12:11 PM, "David Menendez" wrote:

On Mon, Jul 11, 2016 at 8:23 PM, David Feuer wrote:

...

The catchJust and handleJust functions seem a bit weird and unidiomatic.

catchJust :: Exception e => (e -> Maybe b) -- ^ Predicate to select exceptions -> IO a -- ^ Computation to run -> (b -> IO a) -- ^ Handler -> IO a catchJust p a handler = catch a handler' where handler' e = case p e of Nothing -> throwIO e Just b -> handler b

This takes two functions and then puts them together. I would think the more natural API would be

catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a catchMaybe m handler = catch m handler' where handler' e = fromMaybe (throwIO e) (handler e)

This is exactly as powerful as catchJust:

catchMaybe m handler = catchJust handler m id catchJust p m handler = catchMaybe m $ fmap handler . p

But catchMaybe doesn't enforce the arbitrary separation between "selection" and "handling”.

I wouldn’t call it an arbitrary separation. I imagine that the separation is deliberate, because you will frequently want to catch the same set of exceptions, but want to do different things in different contexts. With the current API, you can write a selector like “fileNotFound” and re-use it with multiple handlers.

In constrast, with a unified seletor/handler you have to write the same code to filter the exceptions you want with every handler which deals with them. You might as well just use catch.

-- Dave Menendez http://www.eyrie.org/~zednenem/