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.