On Friday 14 October 2016 at 18:03, Ashish Agarwal wrote:
> With this style, you end up wanting to define a function like:
> val with_file :
> string ->
> f : (t -> (‘a, ‘b) Result.t ->
> (‘a, [> err | ‘b]) Result.t
Not really. 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
Use 1) if `f` erroring has no effect on the bracket (e.g. on reading files).
Use 2) if `f` erroring has an effect on the bracket (e.g. on writing files you
might want not to keep the file if the user function errored).
The client can then decide whether it wants to conflate the client and bracket
errors into a single one by monadically `join`ing them or not.
> The tension is that errors are something you usually want to ignore, but when
> you do want to handle them, you want to do so with a high level of precision.
> (Could algebraic effects help?)
> Somehow what counts as an error and what exact information you might want
> from an error type is less clear than in the Ok case. The Ok case drives your
> functionality. The Error case doesn't. Also, in the Ok case, the library
> author usually knows what to provide. In the Error case, often the library's
> user needs to specify what they need. This reversal leads to more code churn.
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. Simply caring
about the Ok case is equivalent to not doing one's job. The fact that clients
might want to react differently to errors can be catered with by providing
appropriate error value transformations and/or error handling combinators.
MirageOS-devel mailing list