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

[Mindy <mindy@xxxxxxxxxxxxxxxxxxx>]

On 10/04/2016 06:57 AM, Hannes Mehnert wrote:

> 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.
While we're replicating our reactji, I'm also in favor.  I'm currently 
in the middle of assembling PRs for removing id types, but I'll be on a 
long flight flight tomorrow and might be able to put together a 
`result`-y `tcpip` then (power availability permitting).
> > 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.
I'm happy to share acquired wisdom on approaches to this that don't work 
with someone who wants to take it up, but I'm not willing to put any 
more time into attempting to get this to work myself.  I'm also very 
happy with Hannes's solution, which is now merged, for getting us better 
connect-time error reporting.
> > 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?
There's a larger discussion to be had about the proper scope of behavior 
to be implemented in `connect`, but my intuition is that it should fail 
completely and early rather than allowing the unikernel to continue in a 
potentially dangerous or incomplete state.
-Mindy

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