You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@empire-db.apache.org by Harald Kirsch <ha...@raytion.com> on 2014/10/24 09:43:57 UTC
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%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.
Re: Transactions, Exceptions and Empire-db
Posted by Harald Kirsch <ha...@raytion.com>.
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" <harald.kirsch@raytion.com
> <ma...@raytion.com>> 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.
>
Re: Transactions, Exceptions and Empire-db
Posted by Francis De Brabandere <fr...@gmail.com>.
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" <ha...@raytion.com> 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) 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.
>
>