You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Daan Hoogland <da...@gmail.com> on 2014/02/07 11:30:59 UTC
[DISCUSS]null pointer returned from daoimpl
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
Re: [DISCUSS]null pointer returned from daoimpl
Posted by Daan Hoogland <da...@gmail.com>.
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
<Ch...@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" <da...@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
Re: [DISCUSS]null pointer returned from daoimpl
Posted by Chiradeep Vittal <Ch...@citrix.com>.
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" <da...@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