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
smime.p7s
Description: S/MIME cryptographic signature
