Haskell approaches to error handling

Viewed 3302

No argument here that there are a variety of mechanisms in place in Haskell to handle errors and properly handle them. Error monad, Either, Maybe, exceptions, etc.

So why is it that it feels much more straightforward writing exception-prone code in other languages than in Haskell?

Let's say I'd like to write a command line tool that processes files passed on the command line. I'd like to:

  • Verify filenames are provided
  • Verify files are available and readable
  • Verify files have valid headers
  • Create output folder and verify output files will be writable
  • Process files, erroring on parsing errors, invariant errors, etc.
  • Output files, erroring on write error, disk full, etc.

So a pretty straight file processing tool.

In Haskell, I'd be wrapping this code in some combination of monads, using Maybe's and Either's and translating and propagating errors as necessary. In the end, it all gets to an IO monad where I am able to output the status to the user.

In another language, I simply throw an exception and catch in the appropriate place. Straightforward. I don't spend much time in cognitive limbo trying to unravel what combination of mechanisms I need.

Am I simply approaching this wrong or is this there some substance to this feeling?

Edit: Okay, I'm getting feedback telling me that it just feels harder but actually isn't. So here is one pain point. In Haskell, I'm dealing with stacks of monads, and if I have to handle errors, I'm adding another layer to this monad stack. I don't know how many lift's and and other syntactic litter I've had to add just to make the code compile but adds zero semantic meaning. No one feels this adds to the complexity?

3 Answers
Related