Haskell IO and exceptions
All this talk of IO and exceptions reminds me of a small issue I've been having. I like Control.Monad.Error but often my stuff is threaded through the IO monad so, AFAICT from the functional dependency stuff, that means my errors have to be IOErrors. Is that right? And, then, I want control over what's actually reported to the user, but if I make a userError than the consequent message (where the details are presumably platform-dependent) is wrapped up in extra text that I didn't want appearing. Can I use Control.Monad.Error for IO monad stuff such that I can control what string will appear when my error handler tries to "show" my exception? Admittedly, I'm still learning my way around this bit of the standard libraries, so I may have missed something obvious. -- Mark
On 2004 December 02 Thursday 09:35, Mark Carroll wrote:
I like Control.Monad.Error but often my stuff is threaded through the IO monad so, AFAICT from the functional dependency stuff, that means my errors have to be IOErrors. Is that right? And, then, I want control over what's actually reported to the user, but if I make a userError than the consequent message (where the details are presumably platform-dependent) is wrapped up in extra text that I didn't want appearing. Can I use Control.Monad.Error for IO monad stuff such that I can control what string will appear when my error handler tries to "show" my exception?
Yes. Although Control.Monad.Error forces your error type to be in the Error class, that puts no constraints on what you save in the errors. If you thread your errors with the IO Monad then you would be using the monad: ErrorT YourErrorType IO When you invoke runErrorT (within the plain IO monad) it returns an Either result which delivers your error type and it can be reported however you wish. Note that there is no integration between the error tracking of ErrorT, and IO error handling. If your code currently calls userError, it would have to be modified.
On Sun, 5 Dec 2004, Scott Turner wrote: (snip)
Yes. Although Control.Monad.Error forces your error type to be in the Error class, that puts no constraints on what you save in the errors. If you thread your errors with the IO Monad then you would be using the monad: ErrorT YourErrorType IO When you invoke runErrorT (within the plain IO monad) it returns an Either result which delivers your error type and it can be reported however you wish. (snip)
Thanks very much! With the help of the StateT example I already had on the Haskell Wiki I managed to figure out that, to have String errors in ErrorT for code in the IO monad, I could just pass the strings to throwError, change the IO Foo functions from which errors might propagate to ErrorT String IO Foo functions, catch the error in the IO monad with runErrorT (from the Either), and where I have a function that might throw an error that uses the result of a normal IO monad function, I lift that result into the ErrorT monad. And it all seems to work. (-: -- Mark
participants (3)
-
Mark Carroll -
Mark Carroll -
Scott Turner