Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm trying to really master Haskell error handling, and I've gotten to the point where I don't understand why I would use Control.Exception instead of Control.Monad.Error.

The way I can see it, I can catch Control.Monad.Error exceptions in both pure and impure contexts. By contrast, exceptions defined in Control.Exception can be caught only in impure/IO contexts.

Given that they provide two separate interfaces and semantics that I would need to memorize, under what circumstances would I need Control.Exception instead of Control.Monad.Error?

share|improve this question
    
I'm hardly over the monad hump in Haskell but I've heard people say specifically exception is for the you may do nothing more scenarios, like if someone typed cat <file> and the user has no permissions to the file, the program may do nothing more at all towards a useful end type of scenarios like that. Just guessing here as I'm not particularly familiar with the Control.Monad.Error package and it's behaviour. –  Jimmy Hoffa Jan 4 '13 at 23:27
1  
Actually, Jimmy, there is a page that seems to be used in general in Haskell to define the difference between an Exception and an Error. You are describing an error, and in that case you actually flat-out call "error abcdefg". Exceptions are things that can happen (like file not found or invalid format) that you may want to recover from. Unfortunately, Control.Monad.Error is for Exceptions, not errors. –  Savanni D'Gerinel Jan 4 '13 at 23:37
    
Told you I'm hardly over the monad hump :) –  Jimmy Hoffa Jan 5 '13 at 0:24

1 Answer 1

up vote 5 down vote accepted

Control.Exception is designed for use:

  • in otherwise pure code where the addition of an error-related monad or other error reporting structure would be too cumbersome
  • in cases where one thread or process needs to raise an asynchronous exception in another process, outside of the type system's constraints.

For an example of the first, take division by 0 in the Int type (e.g. div 3 0). You can't give a reasonable answer in that case, but you don't want your divide operator to return a Maybe Int – it could make programmers miserable! So you could use an exception to stop the computation.

In this situation, you could also use error for a similar effect. The difference is that Control.Exception gives you more flexibility for catching and reporting what happened. But such exceptions can only be caught in the IO monad, which could place a burden on your client. Therefore, I'd suggest you save these for truly exceptional, perhaps catastrophic situations.

The stuff in Control.Monad.Error works via a monad, and uses the monadic binding/sequencing machinery to pass the error along. It doesn't subvert the type system like throw does, so it has the virtues of purity and relative transparency going for it. It also gives you more flexibility to handle and recover from errors, and can also make it easier to pass errors back to the client if you're writing a library (see Parsec and polyparse, which both transform some monadic error + result into an Either value when they're done, though polyparse uses something a bit different from Control.Monad.Error). But of course you have to work within the error-handling monad, or wrap an error-handling monad transformer around whatever existing monads you might be working in. Both options can make your code considerably more complex.

If you haven't already, see Real World Haskell, Chapter 19 for a rundown of these and other error-handling options, and see the end of Chapter 18 for some of the more general drawbacks of using monads and monad transformers.

share|improve this answer
    
I've read portions of Real World Haskell several times, but it feels very dated. Frequently I'll be working through a chapter and unable to even get the code to compile because, ultimately, the supporting standard libraries changed a long time ago. Chapter 19 was giving me trouble because I couldn't make the leap so that the advice there mesh with the opinions on other more modern pages. –  Savanni D'Gerinel Jan 7 '13 at 15:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.