There are too many error handling conventions used in library code!

[Eric Kidd]

On 3/11/07, Udo Stenzel <u.stenzel at web.de> wrote:
> do uri    <- maybe (fail "broken uri") return  $  parseURI uriStr
>    doc    <- either throwDyn return           =<< evenSimplerHTTP uri
>    parsed <- either throwDyn return            $  parse grammar uriStr doc
>
> ...untested of course, and only intended to show the principle.

Ah, thank you for the interesting example! There are definitely some
good ideas here.

But I'm still concerned that this approach won't scale. In languages
with better-developed library archives (Ruby, Perl, etc.), I
frequently use over a dozen third-party libraries in one program. And
that's the direction Hackage and cabal-install will be taking the
Haskell community.

I'm very sensitive to noise in code. I want my programs to be
uncluttered, perhaps even beautiful (though I rarely achieve that
goal). So the idea of using a bunch of little helper functions to
adapt all the different error-reporting conventions bothers me.

I mean, why is the error-reporting so interesting that it belongs
right in the main program flow? In general, Haskell encourages
programmers to hide irrelevant details in monads, and keep the main
program clean. This would certainly be easier if we had more
consistent error-reporting styles.

But for now, at least, I'll definitely benefit from your suggestions.
Many thanks!

Cheers,
Eric