; already independed of logging frameworks so why not make more use of it?
> I would like to have a in my developing environment
> and in my production code. Is this a good idea?
> I would give it a try if you don't mind.
>
>
>
> Subject: Re: Re-2: Logging in iBatis
n code. Is this a good idea?
I would give it a try if you don't mind.
Subject: Re: Re-2: Logging in iBatis 3 (13-Jan-2010 1:09)
From:Clinton Begin
To: raup...@e2n.de
Yeah, absolutely. I just realized that reading back the thread, that might not
have been clear...
Nat
Yeah, absolutely. I just realized that reading back the thread, that might
not have been clear...
Nathan's advice is where you should start: Let the exception bubble up and
only catch the ones you can actually do something with.
Clinton
On Tue, Jan 12, 2010 at 2:01 PM, Nathan Maves wrote:
> T
There are times when you have an expected exception case. Now I know
that statement contradicts itself but move on :)
I have seen DB check constraints that throw unique exceptions. That
being said you should know that the table/proc/function might throw
these and you need to recover from them.
The idea is that you should rethrow it. I do all of this in one central
class. All of my service classes have the sqlSession instance injected into
them with Guice. I don't commit/rollback or deal with exceptions. I just
get my mappers, do my work, and let the container take care of the rest.
The idea is that there is, typically, nothing you can do with a
database related exception except apologize to the user and move on.
So there is no reason to catch these exceptions everywhere. Catch it
one place - in your application's top level error handling routine and
ignore it everywhere else.
try {
// insert, update or delete
session.commit();
} catch (IbatisException e) {
log.warn(e.getMessage());
} finally {
session.close();
}
Now I catch a unchecked exception. I don't know. Feels awkward.
Subject: Re: Logging in iBatis 3 (12-Jan-2010 16:30)
From:Clinton Begin
