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 <ric...@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 <t...@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-unsubscr...@ibatis.apache.org
>>> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>>>
>>
>>
