Proposal: Add Eq instance for Control.Exception.ErrorCall

[Henning Thielemann]

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.