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

[Yaron Minsky <yminsky@janestreet.com>]

Oh, and as for the thread part of your point, I would strongly
recommend using a monadic concurrency library like Async or Lwt rather
than coding with system threads in OCaml.  It does kill your
stack-traces (stack-traces and monadic libraries don't work so well
together), but it's totally worth the trade-off.  Certainly your
deadlock and race-condition problems get a hell of a lot better.

y

On Wed, Apr 10, 2013 at 7:35 PM, Yaron Minsky <yminsky@janestreet.com> wrote:
> Chet, are you sure that one looses the stack trace in this case?  My
> example using Core seems to preserve it.  Here's the code:
>
>     open Core.Std
>
>     let a () = let _ = "a" in raise Not_found
>     let b () = let _ = "b" in a ()
>
>     let c () =
>       let _ = "c" in
>       protect ~f:b
>         ~finally:(fun () -> ())
>
>     let d () = let _ = "d" in c ()
>     let () = d ()
>
> And here's the native code stack-trace:
>
>     $ ./z.native
>     Fatal error: exception Not_found
>     Raised at file "z.ml", line 3, characters 32-41
>     Called from file "lib/exn.ml", line 63, characters 8-11
>     Re-raised at file "lib/exn.ml", line 66, characters 12-15
>     Called from file "z.ml", line 11, characters 26-30
>
> Here's the code for protect, which is a little different than your
> finally, but not by a lot.  Maybe the biggest difference is that we
> have a special exception (Finally) which we use when the finally
> clause throws an exception from an exception handler, so we can
> deliver both the exception tha triggered the [finally] and the
> exception thrown by the [finally].
>
> This is from the Exn module in Core.
>
>     let protectx ~f x ~(finally : _ -> unit) =
>       let res =
>         try f x
>         with exn ->
>           (try finally x with final_exn -> raise (Finally (exn, final_exn)));
>           raise exn
>       in
>       finally x;
>       res
>     ;;
>
>     let protect ~f ~finally = protectx ~f () ~finally
>
>
> On Wed, Apr 10, 2013 at 6:16 PM, Chet Murthy <murthy.chet@gmail.com> 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--
>>
>>
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs