Re: [MirageOS-devel] FLOW errors

[Thomas Leonard <talex5@xxxxxxxxx>]

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

>> 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
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel