Proposal: Add Eq instance for Control.Exception.ErrorCall
lemming at henning-thielemann.de
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
> 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