Hi Francis,
I was not quite sure myself what the best way to handle this would be,
but I think in my second answer to Rainer's question I finally come to
my conclusion: if the decision is for unchecked exceptions, they should
be documented in the API.
Regards,
Harald.
On 25.10.2014 09:15, Francis De Brabandere wrote:
Hi Harald,
It's not very clear what you want to point out.
So you would rather see checked exceptions? Or better javadoc? Or just
throwing SQLException all over the place? Or a better exception hierarchy?
Transactions are mostly handled at a higher level. (Container/request/...)
Cheers,
F
On Oct 24, 2014 9:45 AM, "Harald Kirsch" <[email protected]
<mailto:[email protected]>> wrote:
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%20to%20Document%__20Runtime%20Exceptions.html
<http://theknowledge.me.uk/mywiki/concepts/exceptions/The%20Need%20to%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.
