On Mon, Oct 17, 2016 at 3:18 PM, Daniel Bünzli <daniel.buen...@erratique.ch>
wrote:
You want to make a clear distinction between the errors of the bracket and
> those of the client function (especially if these end up having overlapping
> cases) so you rather want either:
>
> 1) string -> f:(t -> 'a) -> ('a, [> err]) result
> 2) string -> f:(t -> ('a, 'b) result) -> (('a, 'b) result, [> err]) result
>
True, these are even more precise, but the types are getting even more
hairy now. Are there good combinators that help you anymore, or do we end
up doing a lot of explicit match cases.
I find these claims dubious. For example in distributed computing or
> networking, handling connection errors drives as much your functionality as
> the connected (Ok) case.
>
> Finding an API's error handling strategy is the cornerstore of API design,
> once you have figured that out and your names you are mostly done.
I agree that good error handling is critical and library writers should
strive to make it possible. I might even go further and say the binary
Ok/Error separation is superficial. Whether we call something an error or
not, or whether it is a cornerstone or merely important, the issue is we
don't have a good way of writing code where every function might return a
different set of variant constructors, and you want to handle a subset of
them to varying degrees._______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
