A new version of cookies package - now named http-cookie- has been released to opam. This version has been rewritten to remove all its external and ppx dependencies and now only depends on stock ocaml and its stdlib.
http-cookie is a RFC 6265 compliant HTTP cookie library. RFC 6265 is a HTTP cookie standard specifying cookie data validity requirements.
Additionally, I have also removed the use of Result.t from the previous version and have used plain old exceptions to denote any cookie data validation errors.
It seems that your exceptions/errors are targeted at developers. Result type is useful when errors are a possibly recoverable event encoded in the business logic. Although the distinction here is not clear some cases clearly belong to the former category and some to the latter.
The error in the result could mean “email already taken” or “password is not secure enough according to policy X”. This information could go straight to the user, so they can try again and recover. But the function could also raise an exception if the database is down, this is typically not recoverable by the user.
My two cents is the reasons you’re not a big fan of results is one of the reason I am a fan. Specifically: when a new error condition is added to a piece of code I want it to spread its tentacles throughout the codebase so I know it’s being handled in every call-site.
A common development pattern for me is starting a module with type err = [ `Error ] and once I’ve got it pretty done and I feel confident I understand what the errors should be, turn err into a more descriptive type and then I can go find all places and ensure they handle all those errors properly now. I’m not saying your perspective is wrong, just offering the alternative view. For developing in utop I make a fair amount of use of CCResult.get_exn.