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