cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: [DISCUSS]null pointer returned from daoimpl
Date Sun, 09 Feb 2014 19:13:14 GMT

I think you mean throwing a runtime exception or returning null is
equivalent. A checked exception would enforce handling of the empty
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
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?


On Fri, Feb 7, 2014 at 11:37 PM, Chiradeep Vittal
<> 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" <> wrote:
>>in PrivateIpDaoImpl a null pointer is returned when no db object can be
>>    @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
>>In my opinion a null should never be returned by a dao, at most a vo
>>containing a null but this seldom makes sense.


View raw message