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

[MirageOS-devel] Using Result instead of Option in libraries


  • To: mirageos-devel <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Anil Madhavapeddy <anil@xxxxxxxxxx>
  • Date: Fri, 14 Oct 2016 14:51:01 +0100
  • Delivery-date: Fri, 14 Oct 2016 13:51:09 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=recoil.org; h=from :content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; q=dns; s=selector1; b=P+ptHSm1S0s8UBXOCnNZrG0H GYFVdeOb9x/MeDJUpfbHexmOe+yw8Uj/OiCW1M810JgAuzWupjqZJsZjXaPavhfN 6B4RrhY+ncN04mFK3MH/p46GHx7McdwIk2vEhgRV+YZ+69YqU9SLwMlKeFcAFheT 2Edt9rNYg8Q0fRdbiUI=
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

We have quite a few base libraries that use the pattern of

val foo_exn : ... -> 'a
@raises

val foo: ... -> 'a option
Gobbles the exception and returns Some/None

Should we take the Mirage3 opportunity to port libraries like Ipaddr to using 
the Result type instead, so it would be

val foo : ... -> ('a, [`Msg of string]) result

instead, using the Result type?  That would let libraries use combinators such 
as Rresult, and not gobble errors from parsing silently.  It would be an 
incompatible API bump so we would need to bump all consumers of, e.g. Ipaddr  
http://docs.mirage.io/ipaddr/Ipaddr_unix.V4.html simultaneously.

Anil

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

 


Rackspace

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