[Haskell-cafe] Haskell and the Software design process

[Casey McCann]

On Tue, May 4, 2010 at 9:09 AM, Limestraël <limestrael at gmail.com> wrote:
> Are there other methods than Maybe or exceptions to handle the errors in
> Haskell? Is the monad Error(T) useful?

I believe the usual Error monad is just (Either e), with Left
indicating failure. It's the same idea as Maybe, only returning
information about the error instead of simply Nothing. At any rate,
earlier you said:

> The Maybe method is the simplest but it also comes with a little overhead, since you always have to unpack the Maybe a value return

...which sounds odd to me. If you have a complex computation, in which
many subcomputations can fail, it makes perfect sense to lift the
whole thing into an error-handling monad. Particularly at points where
nothing sensible can be done with a Left or Nothing, unpacking the
result is unnecessary; instead, leave it as is and continue the
computation inside the monad. Then, unpack the value at whatever point
that you actually need the result, or can handle errors gracefully.

I'd actually argue that error handling with Maybe/Either is the single
best, most persuasive use for monadic structure in code--it's
certainly the thing I miss most in other languages. For something so
simple (the entire implementation of Maybe with instances is shorter
than this message!) it's amazingly useful, letting you simplify code
while simultaneously having static assurance that you won't get
runtime errors because of not checking for failure somewhere.

Using "fromJust" or "maybe (error foo) ..." seems bizarre, as if
trying to recreate in Haskell the mind-numbing experience of dealing
with unexpectedly null pointers being dereferenced. For that matter,
null references tend to be frustrating to debug for exactly the same
reason that Haskell errors can be: Crashing only when and if the value
is actually needed, not when the null pointer or _|_ is first
introduced.

- C.