Proposal: Deprecate and remove Prelude.catch and System.IO.Error.{catch, try}

Henning Thielemann lemming at henning-thielemann.de
Wed Jan 5 23:55:49 CET 2011


On Wed, 5 Jan 2011, Ian Lynagh wrote:

> On Wed, Jan 05, 2011 at 10:22:34PM +0100, Henning Thielemann wrote:
>>
>> is the best we can have. Why changing the name 'catch' to 'catchIOError'
>> in order to support unqualified import?
>
> http://www.haskell.org/pipermail/libraries/2010-December/015433.html

That doesn't sound like arguments against qualified import. There are two 
approaches: IOError based exception handling and exception handling based 
on existential quantification. First one is provided in System.IO.Error 
(exclusively, after Prelude does no longer export 'catch'), second one is 
provided in Control.Exception. Both solve the same problem (exception 
handling) in different ways, thus they use the same names. This sounds 
like a good idea for me! I can just change the import line and can switch 
between these approaches easily. That's like having 'take' in Data.List, 
Data.ByteString, Data.ByteString.Lazy etc. That's the entire purpose of 
modules and qualified import.
  Now you may object that these approaches can be easily mixed up, throw 
something using Control.Exception, and try to catch it with 
System.IO.Error. The problem from my perspective is, that it was wrong to 
put another exception handling mechanism with hidden exception information 
into IO. With a monad that is explicit about exceptions, or at least 
explicit about the possible existence of exceptions other than IOError, it 
would not be possible to accidentally mix the two approaches. As I said, I 
think that the extensible-exception mechanism is an interim solution and I 
would not like to make the old mechanism look worse (by renaming catch to 
catchIOError and deprecating Prelude.catch) in order to make 
extensible-exception look better.



More information about the Libraries mailing list