【发布时间】:2014-07-22 00:05:15
【问题描述】:
我主要对Either monad 和来自Control.Error 的所有uilitites 感兴趣。阅读errors-1.0: Simplified error handling,我确信纯错误应该与IO错误分开。这意味着error、fail、exitFailure 是应简化为 IO monad 的函数。纯计算可以和将产生条件错误,但确定性。
目前,在使用 folds 时,我遇到了一种情况,数组中的元素可能会产生条件错误,从而导致整个计算无法满足。例如(使用Data.ConfigFile):
type CPError = (CPErrorData, String)
data CPErrorData = ParseError String | ...
type SectionSpec = String
type OptionSpec = String
instance Error CPError
instance Error e => MonadError e (Either e)
get :: MonadError CPError m => ConfigParser -> SectionSpec -> OptionSpec -> m a
dereference :: ConfigParser -> String -> Either CPError String
dereference cp v = foldr replacer v ["executable", "args", "title"]
where
replacer :: String -> Either CPError String -> Either CPError String
replacer string acc = do
res <- acc
value <- get cp "DEFAULT" string
return $ replace ("${" ++ string ++ "}") value res
情况是:我使用了一个复杂类型的 acc,只是因为如果没有找到单个元素进行替换,那么整个值是不可计算的。
我的问题是:这丑吗? 有更好的方法吗?由于一些 IO 检查,我在 acc 中有一些更糟糕的 EitherT CPError IO String 类型的实用程序。
【问题讨论】:
标签: haskell exception-handling error-handling fold either