English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Exceptions considered harmful
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-07-11 (14:30)
From: Richard Cole <rj-cole@i...>
Subject: [Caml-list] Re: Exceptions considered harmful
When I read your examples I wondered how often this situation arises. Is 
it just a symptom of the file interface or is it more general? It occurs 
whenever resources, such as a file descriptor, need to be relinquished, 
which generally is pretty often.

In one programming task that I worked on for some time most of the code 
followed the following pattern.

   1. allocate resources
   2. manipulate resources
   3. free resources

In each step you have to be ready for something to go wrong. Since it 
was in a distributed environment steps 1 2 and 3 were composed of 
concurrent parts, i.e. all resources were allocated concurrently.

In other programming tasks it has not been important to catch errors 
because the effect of the programming stopping or leaking a few 
resources is not serious.

But if you have to catch the errors it is tedious and error prone to 
write massive try catch blocks to catch every error. Our solution was to 
use the command pattern.

type success_or_failure = Success | Failure
class type command =
   method do: clipboard -> success_or_failure
   method undo: clipboard -> unit
   method final: clipboard -> unit
end ;;

Then programs became the construction of object like the following:

let copy_file_cmd_name_args src dst =
   let src_cmd = open_file_cmd src in
   let dst_cmd = open_file_cmd dst in
     seq_execute_cmd [
        par_execute_cmd [src_cmd, dst_cmd],
        copy_file_cmd_fd_func_args src_cmd#file dst_cmd#file

Here serial_execute runs through the commands executing them one by one 
until either it finishes or an error is generated in which case it backs 
out by calling undo. Finally objects are given a chance to release 
resources when final is called.

This way we were sure that resources would be properly accounted for. Of 
course hardware faults or mis-behaving clients can still cause you 
trouble. Particularly tracing which operation first caused a failure and 
what conditions lead to that failure.

It seems to me that if you have to catch errors then you have to 
construct some similar framework in Ocaml. There's no language support 
for writing commands.



To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners