Proposal: Add Eq instance for Control.Exception.ErrorCall

Henning Thielemann lemming at
Tue Nov 27 12:57:04 CET 2012

On Tue, 27 Nov 2012, Simon Hengel wrote:

>> If this is an actual use case, then there is something very wrong.
>> Handling non-empty lists can be done cleanly using various non-empty
>> list types. Or you avoid 'head' by using 'case' or 'viewL'. If
>> instead you plan to catch something then you should use Either,
>> ExceptionalT, ErrorT or IO exceptions. I am afraid that an Eq
>> instance for ErrorCall promotes the abuse of 'error'.
> Please don't get me wrong.  Personally I always prefer pattern matching
> over /exception throwing functions/.  However, I still think making it
> hard to "deal" with exception throw function is the wrong approach.

If you use the exception techniques that I enumerated it is easy to handle 
those exceptions.

> Regarding testing: Failure behavior is part of the public interface of a
> function.  If a function throws an exception (whether I like it or not),
> I'd like to have it documented.  The best way to document something is a
> test case (IMHO).

In my opinion the better way is to document it in the type. This is what 
the Error like monads are about.

More information about the Libraries mailing list