[MirageOS-devel] FLOW errors

[Thomas Leonard <talex5@xxxxxxxxx>]

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

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

Conduit works around this by requiring various specific
implementations of FLOW with know error types and converting between
them. e.g.

   let vchan_error t =
     t >>= function
       | `Error (`Unknown x) -> return (`Error (`Unknown x))
       | `Eof -> return (`Eof)
       | `Ok b -> return (`Ok b)

   let stack_error t =
     t >>= function
       | `Error (`Unknown x) -> return (`Error (`Unknown x))
       | `Error (`Refused) -> return (`Error (`Refused))
       | `Error (`Timeout) -> return (`Error (`Timeout))
       | `Eof -> return (`Eof)
       | `Ok b -> return (`Ok b)

(actually, we could just use casts here)

For TLS, things become more complicated because its error type is:

  type error  = [ `Tls of string | `Flow of FLOW.error ]

(where FLOW is the underlying flow carrying the encrypted traffic)

Note that:

- You can't do anything with an (`Error (`Tls msg)) except report it
as you would an exception, because it's just a generic error. All you
know is it had something to do with TLS.

- Likewise for (`Unknown msg). There's nothing you can do with this
except report it.

- `Timeout seems vaguely useful, except that it might make more sense
for the caller to decide when to time out, rather than the underlying
protocol. The only thing you can do with a timeout (apart from
reporting it) is to retry - which implies the timeout was too short
for the application.

- `Refused seems strange, since we're not connecting, just reading or
writing. Without a reason for the refusal (disk full? permission
denied?) we can't know what to do with it, and even reporting it isn't
going to be much help.

I can see two reasonable approaches:

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

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?


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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