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

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

Le mardi, 3 fÃvrier 2015 Ã 20:25, Thomas Leonard a Ãcrit :

> The problem is that the subclasses get added elsewhere. e.g.
> mirage-types's FS may define Read_only, but an ext4 filesystem might
> define e.g. Read_only_file, Immutable_file and FS_mounted_read_only.
> Ideally, generic code catching Is_read_only should also catch the
> specific cases.

Then rather than [`Read_only] you could define [ `Read_only of error_details ] 
where error_details is a universal type [1]. The Ext4 module would then define:

type ro_error = [ `Read_only_file | â ]

and a projection function from the universal type:  

val ro_error : FS.error_detail -> Ext4.ro_error option

In any case I dont think inheritence/hirerachy is going scale and solve that 
problem well in general. As with any kind of (non multiple) hierarchical system 
you quickly end up wanting to put something in two different branches.



See e.g. https://github.com/samoht/assemblage/blob/master/lib/as_univ.mli

MirageOS-devel mailing list



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