Ditto.
From: Zoran Avtarovski [mailto:zo...@sparecreative.com]
Sent: Thursday, August 27, 2009 4:25 PM
To: iBatis Java Mail List; Clinton Begin
Subject: Re: iBATIS 3.0 selectOne SessionException if no data found
I for one would prefer null. I like the idea of testing for null rather than
ect
Davide.
-Messaggio originale-
Da: Zoran Avtarovski [mailto:zo...@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
Going once, going twice consider it done.
Clinton
On Fri, Aug 28, 2009 at 2:27 AM, Thanh PHAM wrote:
> I agree with Zoran and would prefer to return null on 0 too.
>
> 2009/8/28 Zoran Avtarovski
>
>> Thanks Clinton,
>>
>> I agree with you, at least I think I do.
>>
>> I think only throwin
I agree with Zoran and would prefer to return null on 0 too.
2009/8/28 Zoran Avtarovski
> 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 ob
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
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
...@arasoft.de]
Sent: Thursday, August 27, 2009 9:43 AM
To: user-java@ibatis.apache.org
Subject: Re: iBATIS 3.0 selectOne SessionException if no data found
1. @Rick: Thank you for your solution, I will use it.
2. @Clinton: No, I don't want NULL, an exception is the right approach. But the
exception nee
1. @Rick: Thank you for your solution, I will use it.
2. @Clinton: No, I don't want NULL, an exception
is the right approach. But the exception needs to
have reliable information about the specific
cause, just like the SqlState field in
SqlException, so that one can differentiate
between an e
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 wrote:
> Maybe a bit of a hack but ...
>
> public inter
Maybe a bit of a hack but ...
public interface UserMapper {
public List 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 i
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
11 matches
Mail list logo
