[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.