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

Re: [MirageOS-devel] FLOW errors

On 13 January 2015 at 13:26, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>> 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.

Yes, good point. There's an arms race here: putting the exn forces the
caller to handle it explicitly. Of course, the caller will wrap >>=
into a version that propagates the exception so they can ignore it

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

Another possibility:

3. Add

   val error_message : error -> string

   to FLOW and DEVICE.

That doesn't involve any backwards incompatible changes, just adding a
few new functions. Then modules can expose detailed error types as
return values if desired, but there's no problem producing detailed
error messages when using the generic interfaces.

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



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