Re: [MirageOS-devel] Error handling in Mirage - request for comments!

[Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx>]

Le mercredi, 11 fÃvrier 2015 Ã 16:18, Thomas Leonard a Ãcrit :

> I think someone who wants to advocate this style should check it /
> change it. It probably needs some worked examples showing it being
> used too.

Seems fine.  

However I disagree with most of the system 5 "problems": I think most of the 
presented problems are solved by providing the monadic combinators/operators 
for the error type and I don't see why this system is harder to explain to new 
users: many OCaml libraries already use that scheme.  

Two problem that exist and that are not mentioned is that you'll sometimes have 
to write explicit coercions (which shouldn't be too bad if you always take care 
to give a type name to sets of polyvars) and that type errors could sometimes 
get wild.  

> Yes, by definition. But what should the "intended scope" be, and how
> do we ensure the producer and consumers of the exception agree?

If you assume the only exceptions you'll get are programming errors then one 
point of view is the following: no exception should cross a component boundary. 
 

Mirage components are akin to plugins (except they are statically linked in), 
the only way to robustly deal with that is to protect any call to the component 
against spurious exceptions (here's an example using dynlink and first class 
module [1]).  

This burden can be put either on the component writer by type-forcing her to 
use a trap abstraction or at the component composition level by having a 
wrapping functor that forwards the calls but catches any spurious exceptions.  

In both cases the spurious exception should be converted to an appropriate 
`('a, [>`Internal_error of exn]) result` value so that the user of the 
component can further make a decision of what it wants to do with that. (In the 
linked example we log the spurious exception and return a default ~fail value 
to allow to continue the computation, a combinator could be provided for that).

This may seem heavy (all component functions return at least `('a, 
[>`Internal_error of exn]) result` values) until you realize you can provide 
users with functors that can implement error handling strategies to knowingly 
and robustly liberate you from part of the error handling. E.g. the behaviour 
of the linked example could be implemented by a functor that takes a Log module 
and a component implementation, internal errors would be logged and the functor 
would define a default behaviour for the `Internal_error cases. Altogether I 
think this system is much more robust and has much better compositional 
properties than using implicit exceptions.  

Best,

Daniel

[1] Any call to the dynlinked module is protected by this function:

https://github.com/dbuenzli/webglue/blob/master/src/api/wg.ml#L1364

Here's an example of use:

https://github.com/dbuenzli/webglue/blob/master/src/api/wg.ml#L1574-L1578




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