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 <raup...@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 <clinton.be...@gmail.com>
> To: raup...@e2n.de
>
>
> The SqlException is always within the thrown exception as a chained
> exception.
>
> Clinton
>
>
> 2010/1/12 [e2n] software | Björn Raupach <raup...@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-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org
