Re: [MirageOS-devel] Using Result instead of Option in libraries

[Ashish Agarwal <agarwal1975@xxxxxxxxx>]

On Mon, Oct 17, 2016 at 3:18 PM, Daniel Bünzli <daniel.buenzli@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel