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
