Re: [Caml-list] try...finally , threads, stack-tracebacks .... in ocaml

[simon cruanes <simon.cruanes.2007@m4x.org>]

An interesting solution for the safe resource acquisition/release, I
believe, is the Go statement "defer" [1]. In OCaml, you would write
something like:

let my_fun () =
  Mutex.lock some_lock;
  defer (fun () -> Mutex.unlock some_lock);
  (* critical section to the end of the block *)
  ....
  let final_result = 42 in
  final_result   (* returns, but runs defer-ed statements first *)

In case an exception is thrown before the function returns, defer-ed
statements would still be executed, before the exception is raised again
(with the full stacktrace). Defer-ed statements are executed in the
reverse order of their definitions. It also works for resources like
files, sockets, etc.

Simon

[1] http://blog.golang.org/2010/08/defer-panic-and-recover.html

On 11/04/2013 00:16, Chet Murthy wrote:
> 
> People have previously asked about try...finally support in Ocaml, and
> it's been observed (correctly) that you can write a little combinator
> to give you this support, e.g.
> 
> let finally f arg finf =
>   let rv = try Inl(f arg) with e ->
>     Inr e
>   in (try finf arg rv with e -> ());
> 	match rv with
> 		Inl v -> v
> 	  | Inr e -> raise e
> 
> The problem is, you discard stack-traceback when you rethrow the
> exception.  One can program around this explicitly by capturing the
> backtrace string and appending it to the rethrown exception, but it's
> cumbersome and won't work for exceptions like Not_found that are
> already defined without a mutable string slot.
> 
> It sure would be nice of ocaml had try...finally that preserved the
> traceback information properly .... though maybe it isn't possible.
> Certainly in the case where the finally block doesn't raise any
> exceptions itself (even those that are caught silently), it seems like
> it ought to be possible.
> 
> In an unrelated but similar sense, when programming with threads in
> ocaml, it's easy (easy!) to deadlock your program.  Now, I've been
> writing Java programs for years, and so am aware of how careful one
> must be, and I'm writing my code using a single mutex protecting the
> critical section.  But I forgot and didn't mutex-protect one method --
> what merely printed out the contents of a shared daa-structure, and
> when that printout coincided with a thread actually mutating the
> data-structure, I got a deadlock.  Not hard to track down, and I
> chided myself for being lax.
> 
> But the thing is, in Java (blecch!) I would have been able to use the
> "javacore" facility to get a full-thread stack-traceback, and could
> have used that to get a good idea of where my deadlock was.
> 
> I'm not saying that this is something ocaml should have, but I figured
> I'd ask: are others (who use threads in ocaml) wishing for something
> like this?
> 
> --chet--
> 
> 
>