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