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

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



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

 


Rackspace

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