<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 27, 2012 at 1:12 PM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Tue, 27 Nov 2012, Simon Hengel wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I propose to add an Eq instance for ErrorCall. The main motivation is<br>
to make it more convenient to construct predicates that select specific<br>
exceptions.<br>
<br>
My current use case is testing for expected exceptions. In Hspec[1] we<br>
use predicates for that, e.g.:<br>
<br>
evaluate (head []) `shouldThrow` (== ErrorCall "Prelude.head: empty list")<br>
</blockquote>
<br>
<br></div>
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'.<div class="HOEnZb">
<div class="h5"><br></div></div></blockquote><div><br></div><div>+1 on the proposal. Even if I'm opposed to partial functions, I'm in favor of making it easier to test them reliably.</div><div><br></div><div>Michael </div>
</div></div></div>