Richard Jones wrote:
> It throws Sql_error when it can determine an error.

Another thing I forgot to bring up about error handling.  If an error 
occurs, you generally want to roll back the transaction.  If you're 
using a connection pool, you want to make sure you close the connection 
when you're done with it, regardless of whether the transaction was 
committed or rolled back.  Committing a transaction, rolling back a 
transaction, and closing a connection are all operations that could also 
throw exceptions.  Writing out all those try-with expressions every time 
becomes very verbose and error-prone.  I think this is the sort of 
problem that functional programming is really well suited to.  For 
example, you could have a standard function like this:

let do_f_with_error_handling f conn = ...

It would begin a transaction on the specified connection, run f, handle 
any exceptions by rolling back the transaction (or else commit it if 
there were no errors), then close the connection (also handling any 
errors).  It would return the value returned by f, or if it caught an 
exception, it would throw that exception (after cleaning up).

(This is one of the annoying things about JDBC; I tend to write 
pseudo-functional classes to do this sort of thing in Java, but in Caml 
it would be much more straightforward.)

Ben

-------------------
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