<div dir="auto">This is a question of documentation, not type design. You don't have to consider what exceptions your transitive dependencies might throw—you need to understand what inputs *do* cause your function to fail. If you use head in a safe way or have a call to error in an unreachable case, you shouldn't say anything. On the other hand, if your function fails when the inputs aren't relatively prime, you should document this regardless of whether the failure is an exception you throw explicitly, a result of a partial pattern match or a division by zero four layers of indirection away.<div dir="auto"><br></div><div dir="auto">I definitely expect the author of a function to understand what inputs cause that function to fail. If you don't understand this, you simply don't understand the code you wrote. (Luckily, QuickCheck will probably find any edge cases you missed when writing the function.)</div><div dir="auto"><br></div><div dir="auto">Thinking about it a bit more, there's nothing specific to exceptions here. If your code loops forever when the lengths of the inputs sum to a multiple of seven, that's pretty handy to know from the documentation! </div><div dir="auto"><br></div><div dir="auto">I would also expect the same style of documentation even for errors expressed in the types with whatever your favorite generalization of Either happens to be.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 31, 2018, 19:07 Bardur Arantsson <<a href="mailto:spam@scientician.net">spam@scientician.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 31/08/2018 18.59, Oliver Charles wrote:<br>
> On Fri, Aug 31, 2018 at 5:21 PM Tikhon Jelvis <<a href="mailto:tikhon@jelv.is" target="_blank" rel="noreferrer">tikhon@jelv.is</a>> wrote:<br>
> <br>
>> Deeper questions of partiality aside, if a function can throw exceptions, the documentation should spell this out *explicitly*, ideally also specifying what the type of the exception may be. To me, this is a *minimum* standard to expect from documentation in any language with exceptions.<br>
> <br>
> Is this to be applied transitively? It has to be, to meet your<br>
> criteria, but this is a fairly unrealistic expectation to put on<br>
> library authors. If it's not applied transitively, then the<br>
> documentation creates a false sense of security - "catch these<br>
> exceptions that *I* throw and you're good!". I really think this part<br>
> of exceptions is a tooling problem that we have to solve. Haddock<br>
> should be responsible for figuring this out.<br>
> <br>
<br>
Not to mention the issues of "may throw" declarations for higher-order<br>
functions... (Java checked exceptions are basically broken[1] because of<br>
this. Well, this + the variance issues arising from inheritance and<br>
method signatures, but obviously Haskell doesn't have inheritance, so...)<br>
<br>
Regards,<br>
<br>
[1] They even break "catch" because everybody is forced to wrap<br>
"checked" exceptions in a RuntimeException if signatures don't specify<br>
"may throw anything", so you *also* have to check for wrapped exceptions<br>
in "catch" clauses. Anyway...<br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>