> Where Id prefer to return null on 0, object for 1 and then throw a
TooManyObjects error
>  the name of the error is irrelevant :)
> This way a simple null test is all that is needed in non > exceptional
circumstances.
I agree with Zoran, this is the behaviour I would expect
Davide.
-----Messaggio originale-----
Da: Zoran Avtarovski [mailto:zoran@sparecreative.com]
Inviato: venerdì 28 agosto 2009 5.42
A: iBatis Java Mail List
Cc: Clinton Begin
Oggetto: Re: iBATIS 3.0 selectOne SessionException if no data found
Thanks Clinton,
I agree with you, at least I think I do.
I think only throwing an exception on only more than one object is a great
idea.
In our standard approach we often see requests for objects that have been
deleted. All we do is test for null and then respond appropriately. What
concerns me is that the current approach will have us try, catch, test to
see what caused the error and then respond appropriately.
Where Id prefer to return null on 0, object for 1 and then throw a
TooManyObjects error  the name of the error is irrelevant :) This way a
simple null test is all that is needed in non exceptional circumstances.
Z.
This is an interesting case... It's based on two best practices:
1) You should not use try/catch for flow control. So if you're catching
the exception to deal with a non-exceptional (i.e. normal) case, then you're
probably abusing the exception.
2) It's not a good idea to return null when one was requested.
The idea here is that if you don't know how many results will be returned
(e.g. 0, 1 or N), then you should use selectList(). However, if you do know
that the instance absolutely exists, then you should use selectOne().
If this practice seems like a lot of arm waving and not terribly practical,
then that's what I'd like to hear from people. Otherwise, does anyone agree
with the design? I can easily eliminate the exception on 0 or 1, and
instead only throw an exception on many (which makes sense).
I agree that the exception should be better... but I don't suggest using it
for flow control.
Thoughts?
Clinton
On Thu, Aug 27, 2009 at 5:25 PM, Zoran Avtarovski <zoran@sparecreative.com>
wrote:
I for one would prefer null. I like the idea of testing for null rather than
using try catch
Z.
Rick's suggestion is correct. That was the idea.
Honestly, we don't have to throw the exception, but it is a good in practice
IMHO...
But you all tell me, do you really want to return null?
Clinton
On Wed, Aug 26, 2009 at 11:07 AM, Rick <rickcr@gmail.com
<http://rickcr@gmail.com> > wrote:
Maybe a bit of a hack but ...
public interface UserMapper {
public List<Long> getUserIds(String email);
}
Keep the dao method the same...
public long getUserId(String email) {
but just do a quick check in there on the size of the List returned, and do
what you want with it (throw you own exception if over size 1?)
and then just always return list.get(0)
On Wed, Aug 26, 2009 at 11:21 AM, Thomas G. Schuessler <tgs@arasoft.de
<http://tgs@arasoft.de> > wrote:
In my MySQL db, I have a table 'users' with (amongst others) these fields:
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`email` varchar(120) NOT NULL,
In UserMapper.java I have the following method
public interface UserMapper {
public long getUserId(String email);
}
In UserMapper.xml I have this:
<select id="getUserId" parameterType="string" resultType="long">
SELECT id FROM users WHERE email = #{email}
</select>
My DAO client code looks like this
public long getUserId(String email) throws SQLException {
SqlSession session = sqlSessionFactory.openSession(true);
try {
UserMapper mapper = session.getMapper(UserMapper.class);
long userId = mapper.getUserId(email.toLowerCase());
return userId;
} catch (SessionException sex) {
throw new SQLException("No data found.", "02000");
} finally {
session.close();
}
}
What I am unhappy about is that in order to differentiate between the "no
data found" situation and other cases, I would have to check the
SessionException for the string "Expected one result to be returned by
selectOne(), but found: 0".
This is somehow unsatisfactory (at least to me) since I do not like to trust
that string to never change...
Is there another way to deal with the situation (without an additional
SELECT COUNT...)? Maybe I have not found the optimal way to solve the issue?
Otherwise, I´d like either a specific exception for this (and similar)
cases, or a field with an error code in SessionException.
Thank you for any input on this,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
<http://user-java-unsubscribe@ibatis.apache.org>
For additional commands, e-mail: user-java-help@ibatis.apache.org
<http://user-java-help@ibatis.apache.org>