Hello all, I've been looking at [1] and trying to make tops and bottoms (pardon the pun) of error handling in Haskell. I am still uncertain of what to do. I recognize that there are different areas of code that may have different requirements for errors: * Pure code that is simple enough can probably get away with returning Maybe a * Pure code that has multiple failure modes (the canonical example is parsing) should return a Either e a. The type of e is a little difficult: many standard libraries seem to use String, but coming from Python this seems analogous to the long deprecated "string exceptions", which are quick and easy but not long-term maintainable due to lack of an easy way to match for them. This leads naturally into Either MyError, which is supported using throwError and catchError. * However, [1] specifically warns against using this technique in the IO monad, and I need a way to short circuit execution when a crucial pure operation fails (in Python, this would have just been an uncaught exception). This suggests using ErrorT on IO, however, [1] also claims that this is generally not a good idea, and suggests to use throwDyn (which actually looks like it's been renamed to throw) * Unfortunately, when I've tried to use this technique, I've run up against the fact that throw is implemented using bottom, so if I do a throw in a pure function, the exception might not actually surface up until I'm, say, attempting to print its return value to IO. Denizens on #haskell have instructed me to treat bottom as the bane of existence and opt for stacking ErrorT on IO (it would be nice to know if this was a good idea or bad idea) At which point, I am most thoroughly confused. Pointers, please! Cheers, Edward [1] http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-erro...