Oooops, I should have read my original question again. Empire-db does
have its specific RuntimeException, a StatementFailedException, so it
probably boils down to a bit more documentation. It should not be
necessary to dig into the code to find out which unchecked exception may
come along.
Regards,
Harald.
On 27.10.2014 10:05, Harald Kirsch wrote:
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.
