On Tue, Jul 27, 2010 at 04:08:39PM -0700, Gerald Gutierrez wrote:
> >> Reading the Control.Monad.Error documentation, I see that the Error class
> >> has noMsg and strMsg as its only two functions.
> >> Now, I understand that you can define your own Error instances such as in
> >> example 1 of the documentation, so why the need to always support strings
> >> via noMsg/strMsg ? What uses these? And if in my code, I will never throw
> >> an
> >> error with a string, am I supposed to implement these functions and then
> >> ignore them?
> >>
> >
> I see. So strings must be supported in the case of a bug which cannot be
> caught at compile time? In other words, if I get an error with a string, I'm
> pretty much guaranteed it is a bug, i.e. a pattern match error as the "fail"
> documentation says.
Not at all, depending on the properties of your monad and intent, a
pattern match failure may or may not be considered a bug, So write your
instance appropriately. it is perfectly fine to make pattern match
failure be 'error' if that is what is appropriate for your monad and
usage.
However, the instance definition for Either that mentions Error is
definitely a big misfeature in the library. Non-local returns are
generally useful in many contexts other than errors.
Actually, the 'Error' class in general seems somewhat dubious to me. I
would avoid using or depending on it.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
