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-09 (16:18)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Re: exception safety / RAII ?
On Wednesday 09 March 2005 14:48, you wrote:
> >> Very rarely having problems with something can't save it from being
> >> a very bad practice.  Not explicitly closing your files is (in 99% of
> >> the cases) just sloppy coding.
> >
> > If we're talking about programs which are expected to run for an
> > arbitrary amount of time (servers, the top-level etc.) then yes.

My statements were based on the incorrect assumption that the OCaml GC closes 
files when it collects file handles. As this is not the case, I definitely 
agree with you that not explicitly closing files in OCaml is sloppy coding 
because they will not be closed implicitly.

However, provided you don't need to make any guarantees about when the file is 
closed during the running of the program, I still think that implicitly 
closing a file (or deallocating an external resource) via the GC is not 
sloppy coding. Indeed, this facility can be very useful and can eliminate an 
important class of run-time errors.

> This logic is routinely used in C to simply never call `free' because they
> only run for a short time.  That's a textbook example of "sloppy coding".

I wouldn't advocate never calling free() in a C program, but what is the 
difference between calling free at some unspecified point in the future and 
relying on a GC?

> It's extremely rare that the point in the code where a file can be closed is
> not trivial to find. 

In the case of files, yes. More generally, this can be applied to all sorts of 
external resources where that is not true.

Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists