Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
exception safety / RAII ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-03-08 (11:33)
From: Ville-Pertti Keinonen <will@e...>
Subject: Re: [Caml-list] Re: exception safety / RAII ?
On Mon, 2005-03-07 at 13:47 -0500, Michael Walter wrote:

> My O'Caml is not very fluent, possible "dispose resource" should read
> "resource # dispose". Basically, the idea is to deterministically
> clean up resources, as early as possible (yes, "but it's not as early
> as possible" is besides the point :-). In my experience this
> simplifies resource management and reasoning about it.

You're right, what you describe is often a good way of managing
resources and also standard practice in e.g. Common Lisp (your "using"
function looks a bit like unwind-protect).

In OCaml you need to know what function to use for disposal of the
specific kind of resource.  For the most general approach, you can pass
a function to call in order to dispose of the resource (making it even
more like unwind-protect).

> I have no idea about with finalizers in O'Caml (hence my more
> broad/general statement), but in other languages I've worked with
> there are several limitations which all basically origin in the fact
> that finalization order in these languages was non-deterministic.

This is also true in OCaml.

The current languages that I'm aware of in which people rely on
deterministic finalization are Python and Visual Basic.  In both cases,
it places nasty limitations on the implementation.

IMHO currently the closest to the "best of both worlds" is a good
garbage collector (with non-deterministic finalization) and explicit
management for those resources that need them (file handles are a good
example; in addition to the reasons already mentioned in this thread,
also because they may refer to sockets and to avoid running into file
descriptor limits).

I'm not sure I understand Jon Harrop's concern about using resources
after they've been deallocated.  This has been addressed in the obvious
way (return errors for operations on remaining references) in various
languages for decades, and unlike memory management and type errors,
AFAIK hasn't been a major source of bugs or complaints.