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