<br>Hi <br><br>We've been doing that for a few months (e.g. <a href="https://github.com/biocaml/biocaml/blob/master/src/lib/biocaml_fastq.mli">https://github.com/biocaml/biocaml/blob/master/src/lib/biocaml_fastq.mli</a> )<br>
<br>
<br>In a sense it's great (and we plan to keep doing this):<br>- polymorphic variants force the exhaustiveness of pattern matching (so you do not forget error cases)<br>- (infered) function types fully document anything that may happen inside a function<br>
<br>There are a few annoyances to keep in mind:<br>- the error types must remain open so that ocaml can merge them ( [> ... ])<br> * sometimes this gets in the way, and you spend time type-hacking only for errors that never happen<br>
(e.g. if you want to put a function in a record/object you have then to play with "type 'error t = { x : ... -> (..., .... as 'error) Result.t }" etc.)<br> * sometimes it's difficult to "reopen" polymorphic variant types<br>
- pattern matching does not know how to remove cases:<br> match error with<br> | `db_error e -> .... return ()<br> | other_error -> error other_error (* without annotations, [> `db_error ... ] will remain part of the total error type *)<br>
<br><br>Cheers<br>Seb<br><br><br><br><br><br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 27, 2012 at 3:27 PM, Malcolm Matalka <span dir="ltr"><<a href="mailto:mmatalka@gmail.com" target="_blank">mmatalka@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been playing with writing code that can fail in a lot of ways and<br>
using Result.Monad_infix to make it more readable. I've found that this<br>
only really works well if all of my functions that return a Result.t<br>
have polymorphic variants on the Error side. Is this the suggested best<br>
practice as well? I'm considering just mandating all my code that can<br>
return a Result.t does this.<br>
<br>
Thanks,<br>
/Malcolm<br>
</blockquote></div><br></div>