caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <gerd@gerd-stolpmann.de>
To: Michael Benfield <leftfist@mac.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] exception safety / RAII ?
Date: Sat, 05 Mar 2005 19:44:22 +0100	[thread overview]
Message-ID: <1110048263.5856.14.camel@localhost.localdomain> (raw)
In-Reply-To: <293072a520e3724a0497e6456a8675be@mac.com>

Am Samstag, den 05.03.2005, 13:16 -0500 schrieb Michael Benfield:
> I'm looking at OCaml coming from sort of a C++ background and I'm 
> finding it really exciting.
> 
> There's one thing that worries me though. C++ programmers have been 
> dealing with issues of exception safety for years - it's a complicated 
> problem because coding in the presence of exceptions for all intents 
> and purposes means your function could end at any point, so how can you 
> make sure resources are deallocated? 

This is not as complicated as for C++. Memory is deallocated
automatically by the garbage collector. The remaining resources are
usually handled manually, e.g. for files

let f = open_in ... in
try
  ...  (* code may raise arbitrary exception *)
with
  any_exception ->
    close_in f;
    raise any_exception

If that happens frequently, one can also define higher-order functions
for that purpose, e.g.

let with_in_file f fn =
  try 
    let r = fn f in close_in f; r
  with
    any_exception -> 
      close_in f; 
      raise any_exception

and then

with_in_file 
  (open_in ...)
  (fun f -> ...)

> The C++ solution to this problem 
> is a technique called Resource Acquisition Is Initialization. C++ 
> objects have destructors, which are simply functions that will always 
> be called on exit from a scope - including if the exit is caused by an 
> exception coming up through your function. You make resource release 
> (whether the resource is memory, a socket, whatever) happen in a 
> destructor, and then you are set. This is very handy even disregarding 
> exceptions.
> 
> So I'm just wondering what facilities OCaml has to either implement 
> this concept, or other concepts to help with exception safety? The 
> OCaml manual says: "Also, finalization can be performed by trapping all 
> exceptions, performing the finalization, then raising again the 
> exception". This makes me cringe.

Using finalization functions is often a bad idea. You cannot predict
when they are called. For example, if one tried to close files by
finalization it would be very likely to run out of file descriptors
because finalization is deferred to some unknown point in time in the
future.

The main purpose of finalization is to synchronize O'Caml's memory
management with some foreign mechanism, e.g. because one is calling a
foreign library.

So the simplified answer to your question: There is nothing like RAII,
and one does not miss it, because O'Caml has much better concepts.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------



  reply	other threads:[~2005-03-05 18:44 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-05 18:16 Michael Benfield
2005-03-05 18:44 ` Gerd Stolpmann [this message]
2005-03-07  0:03 ` [Caml-list] " Jon Harrop
2005-03-07  1:32   ` Stefan Monnier
2005-03-07  2:48     ` [Caml-list] " Brian Hurt
2005-03-07 13:30     ` Jon Harrop
2005-03-07 14:37       ` Stefan Monnier
2005-03-07 17:10         ` [Caml-list] " Jon Harrop
2005-03-08 13:07           ` Damien Doligez
2005-03-08 21:56           ` Oliver Bandel
2005-03-09 13:34             ` Damien Doligez
2005-03-09 14:48           ` Stefan Monnier
2005-03-09 16:19             ` [Caml-list] " Jon Harrop
2005-03-09 22:45               ` [Caml-list] Re: exception safety / RAII Oliver Bandel
2005-03-09 23:42                 ` Charles Forsyth
2005-03-10 14:33               ` exception safety / RAII ? Stefan Monnier
2005-03-10 16:52                 ` [Caml-list] " Jon Harrop
2005-03-11 14:46                   ` Michael Walter
2005-03-12 22:54                   ` Stefan Monnier
2005-03-07 15:21       ` [Caml-list] " Michael Walter
     [not found]         ` <200503071729.20117.jon@jdh30.plus.com>
2005-03-07 18:47           ` Michael Walter
2005-03-08  1:10             ` Jon Harrop
2005-03-08 22:19               ` Oliver Bandel
2005-03-08 22:53               ` Daniel Yokomizo
2005-03-09  1:21                 ` [Caml-list] " Jon Harrop
2005-03-09 13:21                 ` Damien Doligez
2005-03-08 11:33             ` [Caml-list] " Ville-Pertti Keinonen
2005-03-08 12:32               ` Richard Jones
2005-03-08 14:17                 ` Michael Walter
2005-03-08 18:28               ` Jon Harrop
2005-03-08 21:34                 ` Damien Doligez
2005-03-09 15:05                 ` Stefan Monnier
2005-03-09 22:30                   ` [Caml-list] " Marcin 'Qrczak' Kowalczyk
2005-03-10 14:20                     ` Stefan Monnier
2005-03-08 21:32       ` [Caml-list] " Oliver Bandel
2005-03-07  3:31   ` [Caml-list] " Michael Walter

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=1110048263.5856.14.camel@localhost.localdomain \
    --to=gerd@gerd-stolpmann.de \
    --cc=caml-list@yquem.inria.fr \
    --cc=leftfist@mac.com \
    /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;
as well as URLs for NNTP newsgroup(s).