-
Notifications
You must be signed in to change notification settings - Fork 16
Protect exception by injecting them in result type #11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Thanks a bunch for this! So is the idea that
Looking at #9 from @OlivierNicole yesterday I noticed that he also uses the result type. He goes a step further though making I'm wondering why you went with an "internal" A different aspect is that a client would have to understand a new type
Simultaneously in #5 @OlivierNicole is trying to let users install |
As far as I know, any executables and libraries can be attributed to a package by the dune files (via |
Thanks for the review.
It's something like that. Some code was copy-pasted, so I put it in a
Indeed, I forget to add the
I used a
But I'm happy to use an explicit |
OK, makes sense.
That's where I was hoping we could make a difference: let pp_exn = fun fmt e -> Format.fprintf fmt "%s" (Printexc.to_string e)
let show_exn e = Format.asprintf "%a" e pp_exn a client using both
I think it would, following the principle of least surprise: OCaml already has a standard result type that users are likely to know. |
This has shaped up great - thanks! (and sorry for the packaging delay!) |
A function returning a value of type
t
and that can raise an exception will return, in its specification a(t, exn) result
Util
module provides aprotect
combinator and aprotected
type constructor to avoid some boilerplate.Some refactoring has been done (
repeat
andprint_triple_vertical
are now in moduleUtil
)