Proposal: Add Eq instance for Control.Exception.ErrorCall

[Simon Hengel]

Henning,

> >I propose to add an Eq instance for ErrorCall.  The main motivation is
> >to make it more convenient to construct predicates that select specific
> >exceptions.
> >
> >My current use case is testing for expected exceptions.  In Hspec[1] we
> >use predicates for that, e.g.:
> >
> > evaluate (head []) `shouldThrow` (== ErrorCall "Prelude.head: empty list")
> 
> 
> 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.

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).

Cheers,
Simon