On Wed, 2 Mar 2011, Henning Thielemann wrote:
On Wed, 2 Mar 2011, Rouan van Dalen wrote:
I would like to know what is the preferred Haskell mechanism for handling exceptions in the IO monad? I am not concerned with mechanisms such as Maybe / Either, but would like to know about exception mechanisms inside the IO monad.
The 2 I know of are: o) throwDyn o) ioError and catch
I do need the exceptions to be extendable. So which is the preferred way to handle exceptions in Haskell for new libs?
I recently had an idea of how to design extensible explicit type safe exceptions in Haskell 98, i.e. with single parameter type classes and non-overlapping instances. It seems to work quite well, the only drawback is that you have to define n^2 instances for n exceptions. This is much inspired by: http://users.dsic.upv.es/~jiborra/papers/explicitexceptions.pdf Consider two exceptions: ReadException and WriteException. In order to be able to freely combine these exceptions, we use type classes, since type constraints of two function calls are automatically merged. import Control.Monad.Exception.Synchronous (ExceptionalT, ) class ThrowsRead e where throwRead :: e class ThrowsWrite e where throwWrite :: e readFile :: ThrowsRead e => FilePath -> ExceptionalT e IO String writeFile :: ThrowsWrite e => FilePath -> String -> ExceptionalT e IO () For example for copyFile src dst = writeFile dst =<< readFile src the compiler automatically infers copyFile :: (ThrowsWrite e, ThrowsRead e) => FilePath -> FilePath -> ExceptionalT e IO () Instead of ExceptionalT you can also use EitherT or ErrorT. It's also simple to add parameters to throwRead and throwWrite, such that you can pass more precise information along with the exception. I just want to keep it simple for now. With those definitions you can already write a nice library and defer the decision of the particular exception types to the library user. The user might define something like data ApplicationException = ReadException | WriteException instance ThrowsRead ApplicationException where throwRead = ReadException instance ThrowsWrite ApplicationException where throwWrite = WriteException Using ApplicationException however it is cumbersome to handle only ReadException and propagate WriteException. The user might write something like case e of ReadException -> handleReadException WriteException -> throwT throwWrite in order to handle a ReadException and regenerate a 'ThrowWrite e => e' type variable, instead of the concrete ApplicationException type. He may choose to switch on multi-parameter type classes and overlapping instances, define an exception type like 'data EE l' and then use the technique from control-monad-exception for exception handling with the ExceptionalT monads. Now I like to propose a technique for handling a particular set of exceptions in Haskell 98: data ReadException e = ReadException | NoReadException e instance ThrowsRead (ReadException e) where throwRead = ReadException instance ThrowsWrite e => ThrowsWrite (ReadException e) where throwWrite = NoReadException throwWrite data WriteException e = WriteException | NoWriteException e instance ThrowsRead e => ThrowsRead (WriteException e) where throwRead = NoWriteException throwRead instance ThrowsWrite (WriteException e) where throwWrite = WriteException Defining exception types as a sum of "this particular exception" and "another exception" lets us compose concrete types that can carry a certain set of exceptions on the fly. This is very similar to switching from particular monads to monad transformers. Thanks to the type class approach the order of composition needs not to be fixed by the throwing function but is determined by the order of catching. We even do not have to fix the nested exception type fully when catching an exception. It is enough to fix the part that is interesting for 'catch': import Control.Monad.Exception.Synchronous (Exceptional(Success,Exception)) catchRead :: ReadException e -> Exceptional e String catchRead ReadException = Success "catched a read exception" catchRead (NoReadException e) = Exception e throwReadWrite :: (ThrowsRead e, ThrowsWrite e) => e throwReadWrite = asTypeOf throwRead throwWrite exampleCatchRead :: (ThrowsWrite e) => Exceptional e String exampleCatchRead = catchRead throwReadWrite Note how in exampleCatchRead the constraint ThrowsRead is removed from the constraint list of throwReadWrite. As I said, the nasty thing is, that the library has to define n^2 instances for n exceptions. Even worse, if an application imports package A and package B with their sets of exceptions, you have to make the exception types of A instances of the exception class of B and vice versa, and these are orphan instances. However I am still uncertain, how sophisticated an exception system really must be. In principle it must be possible to throw exceptions here and there and catch only some of them at several places. But how realistic is that? Isn't it more common that there are only few places, maybe even one place, where exceptions in an application are catched and reported to the user. Isn't it more common that in these few places all possible exceptions are handled? I am afraid that much effort is put into designing a sophisticated exception handling system like control-monad-exception, that needs type extensions, only to see, that in the end it is not good style to use all the features of that system.