Re: [MirageOS-devel] FLOW errors

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

> I'm trying to tidy up my Mirage conduit changes to support TLS.

I agree this is kind of a mess atm.

> One particularly messy aspect is the error handling. V1_LWT.FLOW
> leaves the "error" type abstract, which means that any code accepting
> a generic flow can't handle errors (except by propagating to its
> caller like an exception and requiring its caller in turn to know
> about the underlying flow type, still breaking the abstraction).

We wanted the error to be s-expressable at one point, not sure if it is the 
right move as it won't really help much (appart printing them correctly).

> 1. Have V1_LWT.FLOW define "type error = exn". This reminds people
> that they may want to handle IO errors specially somehow (why?), but
> lets them easily raise them as exceptions, return them, or convert
> them to strings. You can still match on particular exceptions if
> required (e.g. Tls_invalid_certificate_error or similar).

That's a bit weird to have `Error of exn as it is the same as `Lwt.Fail exn` 
which is directly return by `Lwt.state`. I guess it is very similar to point 2. 
appart that you distinguish IO errors from other errors. Not sure what we gain 
exactly.

> 2. Remove the `Error cases from FLOW and just raise exceptions. Then
> IO errors will be treated the same as any other kind of error (e.g.
> aborting the current opertation and being logged to the console).
> 
> Thoughts?

Error handling needs clean-up in general, so if you think you have a good and 
simple solution for a specific case (FLOW here), go for it.

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