[Haskell-cafe] exceptions vs. Either

MR K P SCHUPKE k.schupke at imperial.ac.uk
Tue Aug 3 09:39:14 EDT 2004


>Sometimes the qualification of an error changes while it is propagated.

There was a discussion about this recently (on the ghc list I think)(

The proposed (partial) solution is to use mapException:

mapExceptionIO :: (Exception -> Exception) -> IO a -> IO a
mapExceptionIO f io = Exception.catch io (\e -> throw $ f e)

which would be used like:

main = mapExceptionIO (\x -> ErrorCall $ showString "in main: " $ show x) $ do

Exceptions can be thrown from anywhere, but can only be caught in the IO
monad hence mapException must be in the IO monad.

Map exception allows a kind of 'backtrace' allowing all functions in the  
call stack of a function which throws an exception to annotate the error
message.


Exceptions should only really be used for unpredictcable events, I find
that the defintion of functions like head is lacking rigor... I would 
prefer to see:

head :: [a] -> Maybe a
head (a0:_) = Just a0
head _ = Nothing

I think functions should only throw an exception if they are subject
to the halting problem (the only way to tell if an algorith will fail
is to run that algorith) - head and lots of other functions in the prelude
are not subject to this, and in my opinion should really be returning 
Maybe...

nobody said anything about me previous post about using the type system
to have 'validated' types - does this mean everyone thinks its a good idea,
or was it too off topic - too obvious? 

	Keean.


More information about the Haskell-Cafe mailing list