Hi David,
You could.
The advantage I see is one less layer of catch and rethrow. The disadvantage
is the client needs to package catch and finally code into methods. More
noise, a little more obscurity compared to simply writing the
try-catch-finally around the call to runTransactionTask().
Of c
Hi Adrian,
Ah, the minimalist approach.
So, logging etc is the client's responsibility.
OK by me.
Cheers
Paul Foxworthy
Adrian Crum-3 wrote:
>
> GenericEntityException is caught, the transaction is rolled back, and the
> exception is re-thrown.
>
> -Adrian
>
>
> On 4/28/2011 7:24 PM, Pau
I like the whole idea
Jacques
From: "Adrian Crum"
Good idea - thanks!
-Adrian
On 4/29/2011 9:52 AM, David E Jones wrote:
You could just add methods to your interface to match up with other parts of
the typical try/catch/finally blocks, such as:
void handleError(Throwable t);
void doFinall
Good idea - thanks!
-Adrian
On 4/29/2011 9:52 AM, David E Jones wrote:
You could just add methods to your interface to match up with other parts of
the typical try/catch/finally blocks, such as:
void handleError(Throwable t);
void doFinally();
-David
On Apr 28, 2011, at 8:03 PM, Adrian Cru
You could just add methods to your interface to match up with other parts of
the typical try/catch/finally blocks, such as:
void handleError(Throwable t);
void doFinally();
-David
On Apr 28, 2011, at 8:03 PM, Adrian Crum wrote:
> GenericEntityException is caught, the transaction is rolled ba
GenericEntityException is caught, the transaction is rolled back, and the
exception is re-thrown.
-Adrian
On 4/28/2011 7:24 PM, Paul Foxworthy wrote:
Hi Adrian,
The key point of difference is catches. The rest, as you say, is boilerplate
stuff that can be encapsulated.
Client code could do
Hi Adrian,
The key point of difference is catches. The rest, as you say, is boilerplate
stuff that can be encapsulated.
Client code could do whatever it wanted in catches, and if I'm reading you
right you're proposing encapsulating a standardized catch. That might not be
what the client wants und
I like it, seems less error prone and I don't see any bad consequences using
it.
Bilgin
On Mon, Apr 25, 2011 at 5:13 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
> Setting up transactions properly can be complicated. I've seen cases where
> it was done wrong. Even when it's done
Setting up transactions properly can be complicated. I've seen cases
where it was done wrong. Even when it's done right, it adds a lot of
client code that gets repeated every time a transaction is used. I have
an idea to make transaction handling easier and more reliable:
1. Create an interfac
