# \[ANN\] http-cookie 2.0.0 **URL:** \ **Category:** Community\ **Tags:** announce\ **Created:** [November 28, 2020, 11:05am UTC](https://discuss.ocaml.org/t/ann-http-cookie-2-0-0/6866 "2020-11-28T11:05:17Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![BikalGurung](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/bikalgurung/32/5105_2.png) [@BikalGurung](https://discuss.ocaml.org/u/BikalGurung)\ **Post date:** [November 28, 2020, 11:05am UTC](https://discuss.ocaml.org/t/ann-http-cookie-2-0-0/6866/1 "2020-11-28T11:05:17Z")
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](https://tools.ietf.org/html/rfc6265) 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. - [Github - http-cookie](https://github.com/lemaetech/http-cookie) - [Docs - http-cookie](https://lemaetech.co.uk/http-cookie/) Enjoy! B. ---
**Author:** ![mudrz](https://avatars.discourse-cdn.com/v4/letter/m/8e7dd6/32.png) [@mudrz](https://discuss.ocaml.org/u/mudrz)\ **Post date:** [November 28, 2020, 2:34pm UTC](https://discuss.ocaml.org/t/ann-http-cookie-2-0-0/6866/2 "2020-11-28T14:34:01Z")
thanks for the library > [@BikalGurung](#): > > 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. curious what made you make this choice? ---
**Author:** ![BikalGurung](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/bikalgurung/32/5105_2.png) [@BikalGurung](https://discuss.ocaml.org/u/BikalGurung)\ **Post date:** [December 3, 2020, 5:39pm UTC](https://discuss.ocaml.org/t/ann-http-cookie-2-0-0/6866/3 "2020-12-03T17:39:34Z")
@mudrz Here are some initial thoughts on result vs exn . [https://lemaetech.co.uk/articles/exceptions.html](https://lemaetech.co.uk/articles/exceptions.html) Hope this helps. ---
**Author:** ![wokalski](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/wokalski/32/38_2.png) [@wokalski](https://discuss.ocaml.org/u/wokalski)\ **Post date:** [December 3, 2020, 7:42pm UTC](https://discuss.ocaml.org/t/ann-http-cookie-2-0-0/6866/4 "2020-12-03T19:42:31Z")
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. ---
**Author:** ![Taki](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/taki/32/718_2.png) [@Taki](https://discuss.ocaml.org/u/Taki)\ **Post date:** [December 4, 2020, 12:49am UTC](https://discuss.ocaml.org/t/ann-http-cookie-2-0-0/6866/5 "2020-12-04T00:49:07Z")
> [@wokalski](#): > > Result type is useful when errors are a possibly recoverable event encoded in the business logic @wokalski Cool, just curious if there’s any minimal test case to describe this scenario? ---
**Author:** ![jerben](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/jerben/32/2331_2.png) [@jerben](https://discuss.ocaml.org/u/jerben)\ **Post date:** [December 4, 2020, 6:12pm UTC](https://discuss.ocaml.org/t/ann-http-cookie-2-0-0/6866/6 "2020-12-04T18:12:45Z")
@Taki From my understanding this could be something like user registration on a web app. ```ocaml val register : email:string -> password:string -> (User.t, string) Result.t Lwt.t ``` 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. ---
**Author:** ![orbitz](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/orbitz/32/110_2.png) [@orbitz](https://discuss.ocaml.org/u/orbitz)\ **Post date:** [December 7, 2020, 6:36am UTC](https://discuss.ocaml.org/t/ann-http-cookie-2-0-0/6866/7 "2020-12-07T06:36:57Z")
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`.