
On Fri, 24 Feb 2012, Conrad Parker wrote:
On 23 February 2012 20:18, John Lato
wrote: This irritates me too; I don't think that Haskell exceptions should be used for much of anything, exceptional condition or not.
+1 to the general concept of not using Haskell exceptions in library code.
This depends on what you call "exception". The exception handling part of the IO monad? The general concept of an exceptional situation? I think if you request the value of a variable, but that variable turns out to not exist, then the question was not valid and that is somehow an exceptional situation. Whether this should be handled by IO's exception handling mechanism or by another one is an interesting question. Whether a non-existent variable shall abort the control flow or not, is another one. I do not like the implicit nature of IO exceptions and thus wrote the package explicit-exception. It is Haskell 98 and provides an Either and an ErrorT like type with appropriate name and no 'fail' implementation, thus with unrestricted types of exceptions. In this approach the switch from an aborting getEnv to a non-aborting getEnv just consists of unwrapping the ExceptionalT monad transformer. Btw. the library also contains a suggestion of how to handle asynchronous exceptions, but unfortunately it suffers from a memory leak in practice (at least in GHC). http://hackage.haskell.org/package/explicit-exception