> > Sometimes it's useful to organise errors into a hierarchy ... I don't see > > any way to do this in OCaml. > > You can get this with polymorphic variants, e.g > > type tcp_connection_refused = [`TCP_connection_refused] > type tcp_error = [tcp_connection_refused | `Another_err]
An good example of this is the (autogen) HTTP error code hierarchy in cohttp: https://github.com/mirage/ocaml-cohttp/blob/master/lib/code.mli#L107 <https://github.com/mirage/ocaml-cohttp/blob/master/lib/code.mli#L107> Thomas > > > > On Tue, Feb 3, 2015 at 12:26 PM, Sebastien Mondet <[email protected] > <mailto:[email protected]>> wrote: > > Yes if we just all agree on this type: > http://erratique.ch/software/fut/doc/Fut.html#TYPEresult > <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/index.html> > http://seb.mondet.org/software/pvem_lwt_unix/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/#/25> > http://seb.mondet.org/talks/compose2015/#/26 > <http://seb.mondet.org/talks/compose2015/#/26> > > > > > > > > On Tue, Feb 3, 2015 at 12:10 PM, Daniel Bünzli <[email protected] > <mailto:[email protected]>> 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 > <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#L420-L428> > https://github.com/samoht/assemblage/blob/master/lib/as_conf.ml#L543-L548 > <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#TYPEresult> > http://erratique.ch/software/fut/doc/Fut.html#VAL(& > <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/Fut.html#VAL(&%3E%3E=)>) > http://erratique.ch/software/fut/doc/Futu.html#VALread > <http://erratique.ch/software/fut/doc/Futu.html#VALread> > > [3] > http://erratique.ch/software/fut/doc/Fut.html#VALfinally > <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 > [email protected] > <mailto:[email protected]> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > <http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel> > > > _______________________________________________ > MirageOS-devel mailing list > [email protected] > <mailto:[email protected]> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > <http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel> > > > _______________________________________________ > MirageOS-devel mailing list > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
