The log level is controlled by the underlying logging system (we support
commons-logging, log4j, slf4j and jdk14 logging).
In my environment, I have separate log4j props files for my unit tests and
my production code.
The kinds of errors you're talking about should never make it to production.
Clinton
2010/1/13 [e2n] software | Björn Raupach <raup...@e2n.de>
> Exactly. My problem is not the unchecked exception. In fact I believe thats
> the way to go. Unchecked exceptions for everything that is not recoverable.
> My only problem is if my apps crashes due to an unexpected exception
> I would like to know where it happened. Otherwise I am not better of with
> a checked exception, which I log first - instead of the framework - and
> then throw the runtime exception. That was we way we used to code with
> iBatis2 or plain jdbc.
>
> Nathan is right. There are usually only a small percent of statements that
> need checking and even for these workarounds exists. In case of an unique
> constraints first check if the attribute already exists then insert, for
> example.
>
> However having try-catch blocks around all my expected unexpected
> exceptions
> doesn't ease the feeling that I might have forgotten one. Or think of a DB
> schema change later one. The one insert statement that used to work doesn't
> work anymore and I have no idea why.
>
> What about of having a log a tag within the environment tag? iBatis is
> already independed of logging frameworks so why not make more use of it?
> I would like to have a <log level="debug" /> in my developing environment
> and <log level="warning" /> 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 3 (13-Jan-2010 1:09)
> From: Clinton Begin <clinton.be...@gmail.com>
> To: raup...@e2n.de
>
>
> 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 <nathan.ma...@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 <clinton.be...@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 <raup...@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 <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!
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>
