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

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

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

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.
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?


MirageOS-devel mailing list



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