Chiradeep,
I think you mean throwing a runtime exception or returning null is
equivalent. A checked exception would enforce handling of the empty
return.
I think @Nullable is a good idea. In this case or in cases where there
is queried for lists I would think an empty list is the best thing to
do.
In any case I would prefer setting a architectural guideline for all
code to adhere to, over leaving it to individual api implementations.
Is such a standard set?
thanks,
On Fri, Feb 7, 2014 at 11:37 PM, Chiradeep Vittal
<chiradeep.vit...@citrix.com> wrote:
> There is no good answer IMHO. The designer of the API chose this design.
>
> Throwing a checked exception or returning Null is equivalent.
> Throwing a runtime exception is probably wrong since there may be some
> recovery possible.
>
> We could annotate the method with @Nullable so that the compiler/IDE can
> warn if the caller of the API forgets to check for Null.
>
> On 2/7/14 2:30 AM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote:
>
>>LS,
>>
>>in PrivateIpDaoImpl a null pointer is returned when no db object can be
>>found:
>>
>> @Override
>> public PrivateIpVO allocateIpAddress(long dcId, long networkId,
>>String requestedIp) {
>>...
>> PrivateIpVO vo = lockOneRandomRow(sc, true);
>> if (vo == null) {
>> txn.rollback();
>> return null;
>> }
>>...
>> return vo;
>> }
>>
>>I would expect it to throw a ClodException of some sort and would like
>>to change it to that but recognize that the null pointer could be of
>>significance in cases. Is there a policy on how dao's should return
>>failures?
>>
>>In my opinion a null should never be returned by a dao, at most a vo
>>containing a null but this seldom makes sense.
>>
>>--
>>Daan
>
--
Daan
