Xen project Mailing List

Yes if we just all agree on this type: http://erratique.ch/software/fut/doc/Fut.html#TYPEresult

then we are all compatible without actual library dependencies, thanks to structural typing

I've been abusing this for the past few years, it's great:
http://seb.mondet.org/software/pvem/index.html
http://seb.mondet.org/software/pvem_lwt_unix/index.html
http://seb.mondet.org/talks/compose2015/#/25
http://seb.mondet.org/talks/compose2015/#/26

On Tue, Feb 3, 2015 at 12:10 PM, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:

Le mardi, 3 fÃvrier 2015 Ã 16:55, Christophe Troestler a Ãcrit :
> Please lay down a concrete interface showing of what you mean. I
> think we all agree on the goal of writing robust software, we need to
> move the discussion to concrete proposals.

Sorry don't have the time to work on this; these things come out of writing code. But as a start I don't see what's the problem with the basic result monad everybody knows (e.g. see here [1,2]) along with a few with_resource combinators based on some kind of `finally` [3] and stick to polymorphic variant errors â along, of course, with Format pretty printers for these something that is often annoyingly absent in APIs. And I would completely forget about using lwt's failed state (i.e. only to trap unexpected exceptions at the highest level).

Best,

Daniel

[1]
This deals only with string errors so it should be generalized to [2], but a few of the error handling
combinators may be interesting.

https://github.com/samoht/assemblage/blob/master/lib/assemblage.mli#L708-L744

For example `reword_error` a quick combinator that allows to transform a lower-level error to a higher level one, i.e. give more context higher up when you have the info about what you are doing. Since we are using strings here it's also easy to stack the errors if you wish so (~replace:false argument) from the lowest-level of what went wrong (e.g. the actual utility invocation error) to what you were trying to do (e.g. determine the number of processors in the system) which makes error diagnosis much easier (context + no error info is lost). Not that it wouldn't be impossible with lists of polyvars, but one has to see how it comes out in practice. A few examples:

https://github.com/samoht/assemblage/blob/master/lib/as_conf.ml#L420-L428
https://github.com/samoht/assemblage/blob/master/lib/as_conf.ml#L543-L548

[2]
This is the classical generalized result type for dealing with errors.
http://erratique.ch/software/fut/doc/Fut.html#TYPEresult
http://erratique.ch/software/fut/doc/Fut.html#VAL(&>>=) (http://erratique.ch/software/fut/doc/Fut.html#VAL(&%3E%3E=))
http://erratique.ch/software/fut/doc/Futu.html#VALread

[3]
http://erratique.ch/software/fut/doc/Fut.html#VALfinally
This could also be modified or another version provided to propagate possible errors in the finally handler in the concurrency monad itself.

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

Re: [MirageOS-devel] Error handling in Mirage - request for comments!