You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by ,
e2n,
,
software | Björn Raupach <ra...@e2n.de> on 2010/01/12 16:37:21 UTC
Re-2: Logging in iBatis 3
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 <cl...@gmail.com>
To: raupach@e2n.de
The SqlException is always within the thrown exception as a chained exception.
Clinton
2010/1/12 [e2n] software | Björn Raupach <ra...@e2n.de>
Hello,
short Question: How is logging configured in iBatis 3?
In iBatis2 we used to caught the SQLException, logged it and threw a RuntimeException.
However in iBatis3 there are no checked execptions anymore.
We are using log4j. In log4j.properties we tried:
log4j.logger.org.apache.ibatis=DEBUG
log4j.logger.java.sql=DEBUG
The sql statement logging is nice, but how to record if something goes wrong? Lets say an insert fails because of a constraint? There is some nice output in my unit tests, but I havent't figured out how retrieve the SQL Exection to log the in the application log.
Thanks in advance!
Re: Re-2: Logging in iBatis 3
Posted by Jeff Butler <je...@gmail.com>.
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.
Jeff Butler
On 1/12/10, [e2n] software | Björn Raupach <ra...@e2n.de> wrote:
> 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 <cl...@gmail.com>
> To: raupach@e2n.de
>
>
> The SqlException is always within the thrown exception as a chained
> exception.
>
> Clinton
>
>
> 2010/1/12 [e2n] software | Björn Raupach <ra...@e2n.de>
>
> Hello,
>
> short Question: How is logging configured in iBatis 3?
>
> In iBatis2 we used to caught the SQLException, logged it and threw a
> RuntimeException.
>
> However in iBatis3 there are no checked execptions anymore.
>
> We are using log4j. In log4j.properties we tried:
>
> log4j.logger.org.apache.ibatis=DEBUG
> log4j.logger.java.sql=DEBUG
>
> The sql statement logging is nice, but how to record if something goes
> wrong? Lets say an insert fails because of a constraint? There is some nice
> output in my unit tests, but I havent't figured out how retrieve the SQL
> Exection to log the in the application log.
>
> Thanks in advance!
>
--
Sent from my mobile device
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Re-2: Logging in iBatis 3
Posted by Clinton Begin <cl...@gmail.com>.
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 <na...@gmail.com>wrote:
> 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.
>
> Moral of the story is catch them if you expect them otherwise let them
> roll.
>
> On Tue, Jan 12, 2010 at 12:58 PM, Clinton Begin <cl...@gmail.com>
> wrote:
> > 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.
> >
> > Clinton
> >
> > try {
> > // insert, update or delete
> > session.commit();
> > } catch (IbatisException e) {
> > log.warn(e.getMessage());
> > throw e;
> > } finally {
> > session.close();
> > }
> >
> >
> > 2010/1/12 [e2n] software | Björn Raupach <ra...@e2n.de>
> >>
> >> 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 <cl...@gmail.com>
> >> To: raupach@e2n.de
> >>
> >>
> >> The SqlException is always within the thrown exception as a chained
> >> exception.
> >>
> >> Clinton
> >>
> >>
> >> 2010/1/12 [e2n] software | Björn Raupach <ra...@e2n.de>
> >>
> >> Hello,
> >>
> >> short Question: How is logging configured in iBatis 3?
> >>
> >> In iBatis2 we used to caught the SQLException, logged it and threw a
> >> RuntimeException.
> >>
> >> However in iBatis3 there are no checked execptions anymore.
> >>
> >> We are using log4j. In log4j.properties we tried:
> >>
> >> log4j.logger.org.apache.ibatis=DEBUG
> >> log4j.logger.java.sql=DEBUG
> >>
> >> The sql statement logging is nice, but how to record if something goes
> >> wrong? Lets say an insert fails because of a constraint? There is some
> nice
> >> output in my unit tests, but I havent't figured out how retrieve the SQL
> >> Exection to log the in the application log.
> >>
> >> Thanks in advance!
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
Re: Re-2: Logging in iBatis 3
Posted by Nathan Maves <na...@gmail.com>.
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.
Moral of the story is catch them if you expect them otherwise let them roll.
On Tue, Jan 12, 2010 at 12:58 PM, Clinton Begin <cl...@gmail.com> wrote:
> 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.
>
> Clinton
>
> try {
> // insert, update or delete
> session.commit();
> } catch (IbatisException e) {
> log.warn(e.getMessage());
> throw e;
> } finally {
> session.close();
> }
>
>
> 2010/1/12 [e2n] software | Björn Raupach <ra...@e2n.de>
>>
>> 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 <cl...@gmail.com>
>> To: raupach@e2n.de
>>
>>
>> The SqlException is always within the thrown exception as a chained
>> exception.
>>
>> Clinton
>>
>>
>> 2010/1/12 [e2n] software | Björn Raupach <ra...@e2n.de>
>>
>> Hello,
>>
>> short Question: How is logging configured in iBatis 3?
>>
>> In iBatis2 we used to caught the SQLException, logged it and threw a
>> RuntimeException.
>>
>> However in iBatis3 there are no checked execptions anymore.
>>
>> We are using log4j. In log4j.properties we tried:
>>
>> log4j.logger.org.apache.ibatis=DEBUG
>> log4j.logger.java.sql=DEBUG
>>
>> The sql statement logging is nice, but how to record if something goes
>> wrong? Lets say an insert fails because of a constraint? There is some nice
>> output in my unit tests, but I havent't figured out how retrieve the SQL
>> Exection to log the in the application log.
>>
>> Thanks in advance!
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: Re-2: Logging in iBatis 3
Posted by Clinton Begin <cl...@gmail.com>.
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.
Clinton
try {
// insert, update or delete
session.commit();
} catch (IbatisException e) {
log.warn(e.getMessage());
throw e;
} finally {
session.close();
}
2010/1/12 [e2n] software | Björn Raupach <ra...@e2n.de>
> 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 <cl...@gmail.com>
> To: raupach@e2n.de
>
>
> The SqlException is always within the thrown exception as a chained
> exception.
>
> Clinton
>
>
> 2010/1/12 [e2n] software | Björn Raupach <ra...@e2n.de>
>
> Hello,
>
> short Question: How is logging configured in iBatis 3?
>
> In iBatis2 we used to caught the SQLException, logged it and threw a
> RuntimeException.
>
> However in iBatis3 there are no checked execptions anymore.
>
> We are using log4j. In log4j.properties we tried:
>
> log4j.logger.org.apache.ibatis=DEBUG
> log4j.logger.java.sql=DEBUG
>
> The sql statement logging is nice, but how to record if something goes
> wrong? Lets say an insert fails because of a constraint? There is some nice
> output in my unit tests, but I havent't figured out how retrieve the SQL
> Exection to log the in the application log.
>
> Thanks in advance!
>