From: Dmitry Grebeniuk <gdsfh1@gmail.com>
To: Mehdi Dogguy <caml-list@inria.fr>
Subject: Re: [Caml-list] Lwt and exceptions
Date: Thu, 15 Sep 2011 15:22:29 +0300 [thread overview]
Message-ID: <CAPi0vKW3cKvqfWUegOmZXPr8cXQdO2Z9tDhw6z40J2Mp6UWwfQ@mail.gmail.com> (raw)
In-Reply-To: <4E71CDB8.5020704@dogguy.org>
Hello.
> In fact, I was wondering
> if Lwt's authors would be against adding a function like:
>
> let wrap f x = try Lwt.return (f x) with e -> Lwt.fail e
Not a very good idea, since evaluation of wrap'ped
function's arguments can raise an exception that
won't be caught by wrap, suppose:
let lwt_string_of_int = wrap string_of_int
let () = Lwt_main.run (
lwt_string_of_int (raise Exit) >>= fun s ->
Lwt_io.printf "everything's okay buddies, it's %s\n" s
)
So it's up to the caller to guarantee the absence of
native exceptions. It's bad. If I will ever need to write
such wrapper, I will make it to have type
wrap : (unit -> ('a -> 'b)) -> (unit -> 'a) -> 'b Lwt.t
maybe with the name of function too, and with
early evaluation of first argument, like
let wrap ?(funcname="") u_f =
let r_f =
try
`Ok (u_f ())
with e_f ->
`Error e_f
in
match r_f with
| `Ok f -> fun x ->
try
Lwt.return (f x)
with e_x ->
(* 1.either *)
Lwt.fail (Failure (Printf.sprintf
"error evaluating function %S: %s"
funcname (Printexc.to_string e_x)))
(* 1.or *)
Lwt.fail e_x
| `Error e_f ->
(* 2.either *)
failwith (Printf.sprintf
"the wrapped function %S itself \
raises error: %s"
funcname (Printexc.to_string e_f))
(* 2.or *)
fun _u_x ->
Lwt.fail e_f
(I haven't checked this code! I don't remember
where should I set begin-end or parenthesis in
nested matches in the original syntax, and I don't
want to remember it now.)
I like the uniform error handling. So I have
wrapped the common IO-specific functions
to a library that gives IO_lwt for lwt, IO_direct
for direct OCaml I/O (stdlib), and... functor
functor functor it sometimes.
It uses "bind" and "return", but I'm very unsure
whether the code can be called "monadic IO",
since lwt itself does not respect the monad laws.
But it doesn't matter, since I'm not a academician,
I'm an engineer.
So I'm using
IO.catch : (unit -> 'a m) -> (exn -> 'a m) -> 'a m
even for direct IO computations.
next prev parent reply other threads:[~2011-09-15 12:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-13 18:37 rixed
2011-09-13 19:17 ` Anil Madhavapeddy
2011-09-14 16:15 ` rixed
2011-09-15 12:24 ` Jérémie Dimino
2011-09-15 10:04 ` Mehdi Dogguy
2011-09-15 10:35 ` Anil Madhavapeddy
2011-09-15 12:09 ` Jérémie Dimino
2011-09-15 12:33 ` Mehdi Dogguy
2011-09-15 12:22 ` Dmitry Grebeniuk [this message]
2011-09-15 13:10 ` Jérémie Dimino
2011-09-17 6:38 ` Dmitry Grebeniuk
2011-09-17 9:23 ` Stéphane Glondu
2011-09-17 10:20 ` Jérémie Dimino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPi0vKW3cKvqfWUegOmZXPr8cXQdO2Z9tDhw6z40J2Mp6UWwfQ@mail.gmail.com \
--to=gdsfh1@gmail.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox