Error Handling in Haskell
Posted by edwinb on January 15, 2007
I like to program in Haskell, and typically write theorem provers and compilers and that sort of thing. This typically involves processing of large data structures (syntax trees representing formulas or programs) which might fail at any point. So, usually, I run such functions inside a monad; forexample, part of a typechecker might look like:
typecheck :: Monad m => RawCode -> m (Expression, Type) typecheck (RawApply f a) = do (fgood, ftype) <- typecheck f (agood, atype) <- typecheck a if (domain ftype == atype) then return (Apply f a, codomain ftype) else fail $ "Type error " ++ ftype ++ ", " ++ atype
This way, I can call typecheck recursively on f and a and let the machine deal with what happens if there’s an error, rather than endlessly nesting case expressions.
However, the fact that fail takes a String can be somewhat limiting. What if I want to handle the error in some appropriate way which relies on me knowing the structure of ftype, for example? Or there might be some specific kinds of error I can recover from that I want to handle specially (e.g. if name lookup fails, I might want to look in some other module). I might even just want to translate error messages into a number of languages. This is the sort of thing that exception handling systems in mainstream languages can do quite easily (define an exception which carries the relevant data), but in Haskell I have to make do with a String.
The Haskell library contains an Error type, which I think would handle this sort of situation. But I don’t really like gratuitous use of non-portable features like multi-parameter type classes — I prefer to look for a simpler solution first. I like to keep things simple, so that other people can understand my code fairly easily (Six months from now, I will be one of those other people myself anyway).
[Aside: yes, I do believe Dependent Types make things simpler all round. That's a topic for another day...]
So, anyway, now I do things like this:
data Possibly a b = Success b | Failure a
deriving (Show, Eq, Ord)
failure :: a -> Possibly a b
failure x = Failure x
success :: b -> Possibly a b
success x = Success x
instance Monad (Possibly a) where
(Success r) >>= k = k r
(Failure err) >>= k = Failure err
return = Success
fail s = error $ "Possibly definitely broken: " ++ s
Yes, it’s just like Either (but is Either a a monad? Why not? It seems to obey the monad laws; perhaps there is something I’m missing…) I like my name better for reasons you’ll see from the type of the next function. Now I can write code just like before, letting the monad deal with failure, while having more expressive errors. e.g.
data Broken = TooBig Int | TooSmall Int
doThings :: Int -> Int -> Possibly Broken Int
doThings x y = do x <- check x
y <- check y
success (x+y)
check :: Int -> Possibly Broken Int
check x | x > 5 && x < 20 = success x
| x < 6 = failure $ TooSmall x
| x > 19 = failure $ TooBig x
And then the calling function can handle the error in some appropriate and informative way, e.g.:
run :: Int -> Int -> Int
run x y = case doThings x y of
Success x -> x
Failure (TooSmall x) ->
error $ show x ++ " needs to be at least " ++
show (6-x) ++ " bigger"
Failure (TooBig x) ->
error $ show x ++ " needs to be at least " ++
show (x-19) ++ " smaller"
It seems nice and simple, and a neat way of dealing with errors more nicely in a large program, so there’s probably something deeply flawed with it. Please let me know…
Tom Moertel said
As you suspected,
Either eis indeed an instance ofMonadandMonadError(providedeis an instance ofError). It’s all defined inControl.Monad.Error.Cheers! –Tom
Bryan O'Sullivan said
Yes, Either is a monad.
edwinb said
So it is. I still like my name better
. I guess I missed it for two reasons: firstly, it isn’t listed in the documentation for Control.Monad or Data.Either (I grepped both); secondly, I tend to switch off when I see multi-parameter type classes. Yes, they are nice and useful (and I make them myself occasionally), but there’s often a simpler way… here I’m not entirely sure what Error being a class buys me, but I’m willing to be educated…
augustss said
Personally I never ever use ‘fail’, because it doesn’t really have anything to do with being a monad. And it should go away from the Monad class.
jdgallag said
yes Augustss, I have never understood why fail is in the monad class, and have never seen this point discussed. Anyone have a suggestioin why?