Re: [MirageOS-devel] load/startup time error handling

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

On 04/10/2016 12:04, Anil Madhavapeddy wrote:
> So this leads me to wonder if we shouldn't just bite the bullet and port
> all these interfaces to use Rresult [1] combinators instead.  It does provide
> excellent support for propagating errors, and combinators for mapping
> over result types quite conveniently.

true! I'm all for it (and like Dave's suggestion, as already indicated
https://github.com/mirage/mirage/issues/571#issuecomment-251127391)

Functions which result in runtime (rather than startup time) errors,
such as Flow.connect, read, write, etc., should return a result type.

> In the case of connect, if we made it a `('a,'b) result io` return value we
> would end up with a nice ready-made error string that can be printed,

exactly how would we get that?  one way is by defining error types
together with pretty printers for each, but please look into the code
functoria generates -- I (when looking with Mindy on the code) couldn't
find a way to retain the actual error type to call the correct pretty
printer.  Thomas' proposal added more magic into the mirage tool (e.g.
https://github.com/talex5/mirage/commit/0d510c6627835b3df792db7bc3fb2cba082de540),
which I'd really like to avoid -- no need to put more domain knowledge
into that tool, it already has too much.

> instead of having to catch the Lwt.fail exception and turn it into a string 
> ourself.

As mentioned in my initial mail: if there is an example where we want to
programmatically handle "connect" errors, we should have a result type
for connect.  So far I have not seen such an example.  Have you seen
one?  Is there one in qcow-format?



hannes

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