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

[Malcolm Matalka <mmatalka@gmail.com>]

On top of this, I have also had a lot of success using the Result type
(and associated Monad) instead of Exceptions in Ocaml.  You have to have
a certain level of discipline to enjoy doing it completely but I have
never had a stack-trace issue doing it because you already know where
you have to handle every failure case.

/M

Yaron Minsky <yminsky@janestreet.com> writes:

> 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