Hi Rainer,
sorry for the delayed answer. This is an on-and-off project for me, so I
cannot always immediately response.
Being forced to catch a general Exception has the strong disadvantage of
including all RuntimeExceptions, in particular buggers like
NullPointerException and OutOfMemoryException which I do not want to
catch and handle, at least not in the context we are talking about.
So while the debate whether we want checked or unchecked exceptions may
continue, I think if empire-db generally prefers unchecked exceptions,
it would be good to implement a specific one, something like
UncheckedSqlException or EmpireDbAccessException or whatever. That would
allow to more specifically catch and distinguish db access problems from
really severe problems that allow no meaningful recovery at all.
Regards,
Harald.
On 24.10.2014 10:10, Rainer Döbele wrote:
Hello Harald,
I am not quite sure what your question is.
When executing an SQL Statement we catch exceptions of type
java.sql.SQLException and wrap them inside a StatementFailedException (this is
done in DBDatabase.executeSQL(...)). But it is also possible that you get an
UnexpectedReturnValueException.
We do this to perform logging and to provide a consistent exception interface
(org.apache.empire.exceptions.EmpireException).
You may catch this exception in your code and perform a rollback.
Usually you may want to perform several updates inside a single transaction
like this:
try {
// Update three records in one transaction
rec1.update(conn);
rec2.update(conn);
rec3.update(conn);
db.commit(conn);
} catch(Exception e) {
db.rollback(conn);
}
Regards,
Rainer
from: Harald Kirsch [mailto:[email protected]]
to: [email protected]
re: Transactions, Exceptions and Empire-db
Hi,
looking at the FAQ it says that transactions are my own business when using
empire-db. Fair enough.
Any exceptions thrown during db operations within a transaction should
result in a rollback, but when I look at DBrecord.update(), it does not throw
any exceptions.
Despite the fact that Martin Fowler proclaims "the debate is over"
(cited here:
http://theknowledge.me.uk/mywiki/concepts/exceptions/The%20Need%20
to%20Document%20Runtime%20Exceptions.html)
and wants us to only use unchecked exceptions, I am now left to explore the
source code to figure out into which unchecked exception the inevitable
SQLException is converted during DBrecord.update(). (It is
StatementFailedException.)
And I need to know, because I must catch it to perform the rollback --- at
least this is what I reckon.
Am I right or am I wrong?
Harald.
