Extracting a Maybe value in IO

Question

Given the following:

> (liftM2 fromMaybe) (ioError $ userError "OOPS") (return $ Just "ok")

ghci gives me

*** Exception: user error (OOPS)

Of course, fromMaybe is working correctly:

> (liftM2 fromMaybe) (return $ "not me") (return $ Just "ok")
"ok"

But it seems that the IO operation is being carried out and then discarded:

> (liftM2 fromMaybe) (putStrLn "computing.." >> "discarded") (return $ Just "ok")
computing..
"ok"

Why is this happening? Is there any way to make the IO monad lazier?

Specifically, given value :: IO (Maybe a) what's a (clean, concise) way to say

result <- (liftM2 fromMaybe) err value

and have it unpack result or throw an IOError accordingly?

score 12 · Accepted Answer · answered Dec 16 '11 at 23:02

I don't know that making IO lazier is the right direction here. What you seem to want to do is first get at the Maybe, then eliminate it. This can be written several ways, here's one option:

test :: IO (Maybe a) -> IO a
test = (>>= maybe (ioError $ userError "oops") return)

score 10 · Answer 2 · edited May 23 '17 at 11:48

If you translate from liftM2 to do-notation, it's obvious why your code fails:

do x <- ioError $ userError "OOPS"
   y <- return $ Just "ok"
   return $ fromMaybe x y

This will never go past the first line, as it's unconditionally throwing an exception.

Anthony's suggestion will work fine, but if you don't care about the specific exception thrown, you can also use pattern matching:

do Just result <- value

If the pattern doesn't match, this will call fail, which in the case of the IO monad throws an exception.

> Just x <- return Nothing
*** Exception: user error (Pattern match failure in do expression at <interactive>:1:0-5)

score 5 · Answer 3 · edited May 23 '17 at 12:19

what's a (clean, concise) way to ... unpack [the] result or throw an IOError accordingly?

I recommend you avoid relying on throwing errors. Instead, handle the "error" explicitly:

maybeM :: Monad m => m b -> (a -> m b) -> m (Maybe a) -> m b
maybeM err f value = do
  x <- value
  case x of
    Just y  -> f y
    Nothing -> err

-- This can be written simply as:
maybeM err f value = do
  x <- value
  maybe err f x

-- or even shorter! This is starting to look like Anthony's answer :)
maybeM err f value = value >>= maybe err f

The function's inputs and types should speak for themselves. You use it by giving it an action to perform for the Nothing case, or a function to perform on the value inside for the Just case. For your particular inputs this would look like:

maybeM (ioError $ userError "OOPS") return (return $ Just "ok")

So if you absolutely must, then the "concise way to unpack the result or throw an IOError" would be:

-- compare to fromJust, a function to be avoided
fromJustIO :: IO (Maybe a) -> IO a
fromJustIO = maybeM (ioError $ userError "OOPS") return

Notice how the type signature for this is practically Maybe a -> a, which is the essence of magicMonadUnwrap :: Monad m => m a -> a, which should set off some red flags. However, you can use this atrocity in a simple manner:

result <- fromJustIO value

Although again, I strongly discourage the use of exceptions here. Try handling errors in a more elegant way than simply exploding, by using maybeM and providing an IO action to execute in the event of failure.

Thanks for the concern, but it's a bit unfounded. I'm throwing the errors in a number of second-tier functions that each do their little bit of IO to grab some configuration. The first-tier configuration function tries them all with a "catch" and formats any errors nicely. It allows me to keep my error handling in one place without needing to thread a "handleErr" function through all the second-tier functions. In such a scenario, are errors still a bad idea? — So8res, Dec 20 '11 at 17:52
So8res: personally I'd have the second-tier functions produce `Maybe` values, and then the first-tier config function can either lump them together with something like `sequence` or `<$>` and `<*>`, or handle each potential error separately, as desired. It's a matter of taste, but in my opinion, errors are almost always a bad idea in Haskell, since we have powerful abstractions that let us compose `Maybe`. The throw/catch control flow mechanism doesn't match the FP style that Haskell encourages. — Dan Burton, Dec 20 '11 at 18:48

Extracting a Maybe value in IO

3 Answers3