Re: [Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Nuwan Pallewela]

Hi All,

I also think that using exception for flow control is an anti pattern.
Following [1] describes the best practices in handling exceptions.
And using null references is also not good practice. There is a design
pattern called Null Object Pattern[2] [3] to address this issue. So I think
combining these two we could decide how to approach for certain situation.

[1] http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html?page=1
[2] https://sourcemaking.com/design_patterns/null_object
[3] https://en.wikipedia.org/wiki/Null_Object_pattern

Thanks,
Nuwan


On Mon, Jul 18, 2016 at 1:41 PM, Udara Liyanage  wrote:

> Hi,
>
> It is not performance that matters, using exceptions for flow control is
> an anti pattern [1] [2].
>
> [1] http://c2.com/cgi/wiki?DontUseExceptionsForFlowControl
> [2]
> http://programmers.stackexchange.com/questions/189222/are-exceptions-as-control-flow-considered-a-serious-antipattern-if-so-why
>
>
> On Sun, Jul 17, 2016 at 10:46 PM, Rasika Perera  wrote:
>
>> Hi All,
>>
>>
>>> Considering a method returning a user object the client code should not
>>> be able to proceed further if there is no user.
>>
>>  This is the use case we need to achieve. How do we enforce clients to
>> *not* to proceed if the user is not found? I really do promote Design by
>> Contract . NULL will
>> give over-flexibility here and it is not what we asked for either.
>> Further, it might caused redundant NULL checks and NPEs for FREE.
>>
>> Exceptions are meant to be used for exceptional cases, using them for
>>> flow control is a bad practice. So I don't think it is a good practice to
>>> throw Exceptions instead of returning null. In addition using exceptions is
>>> costly for performance.
>>
>> Yes, Exceptions might be costly if you used it in bad way. Why not for flow
>> control? If your code running happy path most of the times, returning
>> exception on a trap would not be that harmfull. Exceptions are much
>> similar to other objects except the native call fillInStackTrace
>> .
>>  Even
>> Throwable has a constructor without a stacktrace, if you worried on
>> performance. My rule of thumb is; If performance matters so much, you
>> may need to re-consider writing your application in Java instead try C or
>> C++. Java meant to be high-level and code should be self explanatory and
>> maintainable[1]. Please refer "Null References: The Billion Dollar
>> Mistake" by T. Hoare[2].
>>
>> This is my two cents for NULLs ;)
>>
>> Choosing return NULL over Exceptions is a choice of writing *unreliable*
>> applications over bad-performance.
>>
>> Thanks,
>> Rasika
>>
>> [1] http://wolfie.github.io/2010/03/14/exceptional-heresy.html
>> [2]
>> https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
>>
>> On Sun, Jul 17, 2016 at 5:58 PM, Udara Liyanage  wrote:
>>
>>>
>>>
>>> On Sun, Jul 17, 2016 at 2:53 PM, Nuwan Pallewela 
>>> wrote:
>>>
 Hi,

 On Wed, Jul 13, 2016 at 10:15 AM, Sabra Ossen  wrote:

> Hi,
>
> Thank you all for your prompt responses :)
>
> So if it's an ArrayList/Map it's better to return an empty object
> rather than null. Got it.
>
> Regarding a POJO object IMO the usage of null, empty object or
> exception depends on the scenario being considered.
>
> Based on Rasikas' reply since the jaggery level code is using the DAO
> method (via manager interface) basically if no user is found then the
> exception thrown should be propagated and in the UI an appropriate message
> is rendered. Also since anyone else could be using the back end, when an
> exception is thrown they would not have to be aware of the internal
> implementation (if null or an empty object is returned, specifically he
> should be aware if an empty object is returned so that he should write his
> front end code accordingly).
>
> IMO returning an exception is clearer in terms of code but I guess the
> discussion could continue further until a guideline is specified.
>
 +1 for throwing an exception in general. If we return a null or empty
 object if data is unavailable, we may have to do a null check or empty
 object check when trying to process it most probably. And that check may
 tend to hide the original problem of unavailability of data and hard to
 debug if we face an error in a different place because of that.IMO throwing
 a custom exception which we could handle and log later or give an error
 message  to user will be more suitable.
 What to use with ArrayList and Maps is also depends on how we are going
 to manipulate the returned value. If we are going to access data in a
 ArrayList by index calling index values individually, it is 

Re: [Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Udara Liyanage]

Hi,

It is not performance that matters, using exceptions for flow control is an
anti pattern [1] [2].

[1] http://c2.com/cgi/wiki?DontUseExceptionsForFlowControl
[2]
http://programmers.stackexchange.com/questions/189222/are-exceptions-as-control-flow-considered-a-serious-antipattern-if-so-why

On Sun, Jul 17, 2016 at 10:46 PM, Rasika Perera  wrote:

> Hi All,
>
>
>> Considering a method returning a user object the client code should not
>> be able to proceed further if there is no user.
>
>  This is the use case we need to achieve. How do we enforce clients to
> *not* to proceed if the user is not found? I really do promote Design by
> Contract . NULL will
> give over-flexibility here and it is not what we asked for either.
> Further, it might caused redundant NULL checks and NPEs for FREE.
>
> Exceptions are meant to be used for exceptional cases, using them for flow
>> control is a bad practice. So I don't think it is a good practice to throw
>> Exceptions instead of returning null. In addition using exceptions is
>> costly for performance.
>
> Yes, Exceptions might be costly if you used it in bad way. Why not for flow
> control? If your code running happy path most of the times, returning
> exception on a trap would not be that harmfull. Exceptions are much
> similar to other objects except the native call fillInStackTrace
> .
>  Even
> Throwable has a constructor without a stacktrace, if you worried on
> performance. My rule of thumb is; If performance matters so much, you may
> need to re-consider writing your application in Java instead try C or C++.
> Java meant to be high-level and code should be self explanatory and
> maintainable[1]. Please refer "Null References: The Billion Dollar
> Mistake" by T. Hoare[2].
>
> This is my two cents for NULLs ;)
>
> Choosing return NULL over Exceptions is a choice of writing *unreliable*
> applications over bad-performance.
>
> Thanks,
> Rasika
>
> [1] http://wolfie.github.io/2010/03/14/exceptional-heresy.html
> [2]
> https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
>
> On Sun, Jul 17, 2016 at 5:58 PM, Udara Liyanage  wrote:
>
>>
>>
>> On Sun, Jul 17, 2016 at 2:53 PM, Nuwan Pallewela  wrote:
>>
>>> Hi,
>>>
>>> On Wed, Jul 13, 2016 at 10:15 AM, Sabra Ossen  wrote:
>>>
 Hi,

 Thank you all for your prompt responses :)

 So if it's an ArrayList/Map it's better to return an empty object
 rather than null. Got it.

 Regarding a POJO object IMO the usage of null, empty object or
 exception depends on the scenario being considered.

 Based on Rasikas' reply since the jaggery level code is using the DAO
 method (via manager interface) basically if no user is found then the
 exception thrown should be propagated and in the UI an appropriate message
 is rendered. Also since anyone else could be using the back end, when an
 exception is thrown they would not have to be aware of the internal
 implementation (if null or an empty object is returned, specifically he
 should be aware if an empty object is returned so that he should write his
 front end code accordingly).

 IMO returning an exception is clearer in terms of code but I guess the
 discussion could continue further until a guideline is specified.

>>> +1 for throwing an exception in general. If we return a null or empty
>>> object if data is unavailable, we may have to do a null check or empty
>>> object check when trying to process it most probably. And that check may
>>> tend to hide the original problem of unavailability of data and hard to
>>> debug if we face an error in a different place because of that.IMO throwing
>>> a custom exception which we could handle and log later or give an error
>>> message  to user will be more suitable.
>>> What to use with ArrayList and Maps is also depends on how we are going
>>> to manipulate the returned value. If we are going to access data in a
>>> ArrayList by index calling index values individually, it is better to use
>>> exception otherwise we may need to have a null check before that. Same
>>> applies to Maps. If we are going to process each element in a ArrayList we
>>> could use Iterator and process. In that case empty ArrayList would do the
>>> job. So there is not going to be a one for all cases solution in this
>>> argument. It will depend on how we are going to process that returned value
>>> and the nature of the application.
>>>
>> Exceptions are meant to be used for exceptional cases, using them for
>> flow control is a bad practice. So I don't think it is a good practice to
>> throw Exceptions instead of returning null. In addition using exceptions is
>> costly for perfomance.
>>
>> If you return a  empty object the calling 

Re: [Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Rasika Perera]

Hi All,


> Considering a method returning a user object the client code should not be
> able to proceed further if there is no user.

 This is the use case we need to achieve. How do we enforce clients to
*not* to proceed if the user is not found? I really do promote Design by
Contract . NULL will
give over-flexibility here and it is not what we asked for either. Further,
it might caused redundant NULL checks and NPEs for FREE.

Exceptions are meant to be used for exceptional cases, using them for flow
> control is a bad practice. So I don't think it is a good practice to throw
> Exceptions instead of returning null. In addition using exceptions is
> costly for performance.

Yes, Exceptions might be costly if you used it in bad way. Why not for flow
control? If your code running happy path most of the times, returning
exception on a trap would not be that harmfull. Exceptions are much similar
to other objects except the native call fillInStackTrace
.
Even
Throwable has a constructor without a stacktrace, if you worried on
performance. My rule of thumb is; If performance matters so much, you may
need to re-consider writing your application in Java instead try C or C++.
Java meant to be high-level and code should be self explanatory and
maintainable[1]. Please refer "Null References: The Billion Dollar Mistake"
by T. Hoare[2].

This is my two cents for NULLs ;)

Choosing return NULL over Exceptions is a choice of writing *unreliable*
applications over bad-performance.

Thanks,
Rasika

[1] http://wolfie.github.io/2010/03/14/exceptional-heresy.html
[2]
https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare

On Sun, Jul 17, 2016 at 5:58 PM, Udara Liyanage  wrote:

>
>
> On Sun, Jul 17, 2016 at 2:53 PM, Nuwan Pallewela  wrote:
>
>> Hi,
>>
>> On Wed, Jul 13, 2016 at 10:15 AM, Sabra Ossen  wrote:
>>
>>> Hi,
>>>
>>> Thank you all for your prompt responses :)
>>>
>>> So if it's an ArrayList/Map it's better to return an empty object
>>> rather than null. Got it.
>>>
>>> Regarding a POJO object IMO the usage of null, empty object or exception
>>> depends on the scenario being considered.
>>>
>>> Based on Rasikas' reply since the jaggery level code is using the DAO
>>> method (via manager interface) basically if no user is found then the
>>> exception thrown should be propagated and in the UI an appropriate message
>>> is rendered. Also since anyone else could be using the back end, when an
>>> exception is thrown they would not have to be aware of the internal
>>> implementation (if null or an empty object is returned, specifically he
>>> should be aware if an empty object is returned so that he should write his
>>> front end code accordingly).
>>>
>>> IMO returning an exception is clearer in terms of code but I guess the
>>> discussion could continue further until a guideline is specified.
>>>
>> +1 for throwing an exception in general. If we return a null or empty
>> object if data is unavailable, we may have to do a null check or empty
>> object check when trying to process it most probably. And that check may
>> tend to hide the original problem of unavailability of data and hard to
>> debug if we face an error in a different place because of that.IMO throwing
>> a custom exception which we could handle and log later or give an error
>> message  to user will be more suitable.
>> What to use with ArrayList and Maps is also depends on how we are going
>> to manipulate the returned value. If we are going to access data in a
>> ArrayList by index calling index values individually, it is better to use
>> exception otherwise we may need to have a null check before that. Same
>> applies to Maps. If we are going to process each element in a ArrayList we
>> could use Iterator and process. In that case empty ArrayList would do the
>> job. So there is not going to be a one for all cases solution in this
>> argument. It will depend on how we are going to process that returned value
>> and the nature of the application.
>>
> Exceptions are meant to be used for exceptional cases, using them for flow
> control is a bad practice. So I don't think it is a good practice to throw
> Exceptions instead of returning null. In addition using exceptions is
> costly for perfomance.
>
> If you return a  empty object the calling function will invoke functions
> of the object which will result in undesirable state. Some object creating
> initialize some of its members which may be invoked by the calling function
> which we don't intend.
>
> For POJO(I don't have idea about collections) it is OK to return null if
> no data available or simply functions does not have anything to return and
> let the calling function deal with it. You can document return values and
> when it returns null.
>
>>
>>> Regards.
>>>
>>>
>>> On Wed, 

Re: [Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Udara Liyanage]

On Sun, Jul 17, 2016 at 2:53 PM, Nuwan Pallewela  wrote:

> Hi,
>
> On Wed, Jul 13, 2016 at 10:15 AM, Sabra Ossen  wrote:
>
>> Hi,
>>
>> Thank you all for your prompt responses :)
>>
>> So if it's an ArrayList/Map it's better to return an empty object rather
>> than null. Got it.
>>
>> Regarding a POJO object IMO the usage of null, empty object or exception
>> depends on the scenario being considered.
>>
>> Based on Rasikas' reply since the jaggery level code is using the DAO
>> method (via manager interface) basically if no user is found then the
>> exception thrown should be propagated and in the UI an appropriate message
>> is rendered. Also since anyone else could be using the back end, when an
>> exception is thrown they would not have to be aware of the internal
>> implementation (if null or an empty object is returned, specifically he
>> should be aware if an empty object is returned so that he should write his
>> front end code accordingly).
>>
>> IMO returning an exception is clearer in terms of code but I guess the
>> discussion could continue further until a guideline is specified.
>>
> +1 for throwing an exception in general. If we return a null or empty
> object if data is unavailable, we may have to do a null check or empty
> object check when trying to process it most probably. And that check may
> tend to hide the original problem of unavailability of data and hard to
> debug if we face an error in a different place because of that.IMO throwing
> a custom exception which we could handle and log later or give an error
> message  to user will be more suitable.
> What to use with ArrayList and Maps is also depends on how we are going to
> manipulate the returned value. If we are going to access data in a
> ArrayList by index calling index values individually, it is better to use
> exception otherwise we may need to have a null check before that. Same
> applies to Maps. If we are going to process each element in a ArrayList we
> could use Iterator and process. In that case empty ArrayList would do the
> job. So there is not going to be a one for all cases solution in this
> argument. It will depend on how we are going to process that returned value
> and the nature of the application.
>
Exceptions are meant to be used for exceptional cases, using them for flow
control is a bad practice. So I don't think it is a good practice to throw
Exceptions instead of returning null. In addition using exceptions is
costly for perfomance.

If you return a  empty object the calling function will invoke functions of
the object which will result in undesirable state. Some object creating
initialize some of its members which may be invoked by the calling function
which we don't intend.

For POJO(I don't have idea about collections) it is OK to return null if no
data available or simply functions does not have anything to return and let
the calling function deal with it. You can document return values and when
it returns null.

>
>> Regards.
>>
>>
>> On Wed, Jul 13, 2016 at 6:49 AM, Harsha Thirimanna 
>> wrote:
>>
>>> HI Sabra,
>>>
>>> If there is collection type as a return, then you MUST return empty
>>> collection object of instead of null. But if you expect POJO as a return,
>>> then it would be better to return null instead of empty object. Because if
>>> it returns empty object instead of null, then some one get misunderstand
>>> who is going to use that API and will try to consume that as expected
>>> output. Then there may be more problems. You may not be the only one who
>>> consume your backend api.
>>>
>>>
>>>
>>>
>>> *Harsha Thirimanna*
>>> Associate Tech Lead; WSO2, Inc.; http://wso2.com
>>> * *
>>> *email: **hars...@wso2.com* * cell: +94 71 5186770 *
>>> *twitter: **http://twitter.com/ *
>>> *harshathirimannlinked-in: **http:
>>> **//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
>>> *
>>>
>>> *Lean . Enterprise . Middleware*
>>>
>>>
>>> On Wed, Jul 13, 2016 at 12:42 AM, Rasika Perera 
>>> wrote:
>>>
 ​Hi Sabra
 ​
 ​,

 I think you need to handle this error at jaggery level.​

 Considering a method returning a user object the client code should not
> be able to proceed further if there is no user.

 ​In this case, -1 for returning NULL. When there is an error,
 unless
 ​ it is recoverable locally you ​
 *should*
 ​ convey ​it to the upper layers. In your case, If you cannot return a
 user object it is more intuitive to return an exception such as
 UserManagerException.

 By returning NULL, you cannot make it mandatory to handle exception.
 Your client code will not be aware of NULL unless the developer reads your
 implementation class OR the documentation. Try to avoid
 

Re: [Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Nuwan Pallewela]

Hi,

On Wed, Jul 13, 2016 at 10:15 AM, Sabra Ossen  wrote:

> Hi,
>
> Thank you all for your prompt responses :)
>
> So if it's an ArrayList/Map it's better to return an empty object rather
> than null. Got it.
>
> Regarding a POJO object IMO the usage of null, empty object or exception
> depends on the scenario being considered.
>
> Based on Rasikas' reply since the jaggery level code is using the DAO
> method (via manager interface) basically if no user is found then the
> exception thrown should be propagated and in the UI an appropriate message
> is rendered. Also since anyone else could be using the back end, when an
> exception is thrown they would not have to be aware of the internal
> implementation (if null or an empty object is returned, specifically he
> should be aware if an empty object is returned so that he should write his
> front end code accordingly).
>
> IMO returning an exception is clearer in terms of code but I guess the
> discussion could continue further until a guideline is specified.
>
+1 for throwing an exception in general. If we return a null or empty
object if data is unavailable, we may have to do a null check or empty
object check when trying to process it most probably. And that check may
tend to hide the original problem of unavailability of data and hard to
debug if we face an error in a different place because of that.IMO throwing
a custom exception which we could handle and log later or give an error
message  to user will be more suitable.
What to use with ArrayList and Maps is also depends on how we are going to
manipulate the returned value. If we are going to access data in a
ArrayList by index calling index values individually, it is better to use
exception otherwise we may need to have a null check before that. Same
applies to Maps. If we are going to process each element in a ArrayList we
could use Iterator and process. In that case empty ArrayList would do the
job. So there is not going to be a one for all cases solution in this
argument. It will depend on how we are going to process that returned value
and the nature of the application.

>
> Regards.
>
>
> On Wed, Jul 13, 2016 at 6:49 AM, Harsha Thirimanna 
> wrote:
>
>> HI Sabra,
>>
>> If there is collection type as a return, then you MUST return empty
>> collection object of instead of null. But if you expect POJO as a return,
>> then it would be better to return null instead of empty object. Because if
>> it returns empty object instead of null, then some one get misunderstand
>> who is going to use that API and will try to consume that as expected
>> output. Then there may be more problems. You may not be the only one who
>> consume your backend api.
>>
>>
>>
>>
>> *Harsha Thirimanna*
>> Associate Tech Lead; WSO2, Inc.; http://wso2.com
>> * *
>> *email: **hars...@wso2.com* * cell: +94 71 5186770 *
>> *twitter: **http://twitter.com/ *
>> *harshathirimannlinked-in: **http:
>> **//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
>> *
>>
>> *Lean . Enterprise . Middleware*
>>
>>
>> On Wed, Jul 13, 2016 at 12:42 AM, Rasika Perera  wrote:
>>
>>> ​Hi Sabra
>>> ​
>>> ​,
>>>
>>> I think you need to handle this error at jaggery level.​
>>>
>>> Considering a method returning a user object the client code should not
 be able to proceed further if there is no user.
>>>
>>> ​In this case, -1 for returning NULL. When there is an error,
>>> unless
>>> ​ it is recoverable locally you ​
>>> *should*
>>> ​ convey ​it to the upper layers. In your case, If you cannot return a
>>> user object it is more intuitive to return an exception such as
>>> UserManagerException.
>>>
>>> By returning NULL, you cannot make it mandatory to handle exception.
>>> Your client code will not be aware of NULL unless the developer reads your
>>> implementation class OR the documentation. Try to avoid
>>> NullPointerException
>>> ​ as much as possible.​
>>>
>>> In your client code(Jaggery) you can catch this error with try{ }
>>> catch(error){ }. Found this blogpost [1] which discusses on jaggery error
>>> handling.
>>> AFAIK Jaggery will wrap java exceptions with ScriptException object.
>>>
>>> Regards,
>>> Rasika
>>>
>>> [1]
>>> http://ruchirawageesha.blogspot.com/2013/04/error-handling-in-jaggery.html
>>>
>>> On Tue, Jul 12, 2016 at 2:17 PM, Abimaran Kugathasan 
>>> wrote:
>>>
 There are good enough discussion in Stackoverflow [1], [2] and [3]. You
 could return null, empty object or throw exception in the case of data not
 available.

 It's also depends on the type of the Object you are supposed to return,
 if it's a ArrayList/Map, then returning empty ArrayList/Map is better than
 returning null, but, in case of Model object, I think, returning null is
 better than 

Re: [Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Sabra Ossen]

Hi,

Thank you all for your prompt responses :)

So if it's an ArrayList/Map it's better to return an empty object rather
than null. Got it.

Regarding a POJO object IMO the usage of null, empty object or exception
depends on the scenario being considered.

Based on Rasikas' reply since the jaggery level code is using the DAO
method (via manager interface) basically if no user is found then the
exception thrown should be propagated and in the UI an appropriate message
is rendered. Also since anyone else could be using the back end, when an
exception is thrown they would not have to be aware of the internal
implementation (if null or an empty object is returned, specifically he
should be aware if an empty object is returned so that he should write his
front end code accordingly).

IMO returning an exception is clearer in terms of code but I guess the
discussion could continue further until a guideline is specified.

Regards.


On Wed, Jul 13, 2016 at 6:49 AM, Harsha Thirimanna  wrote:

> HI Sabra,
>
> If there is collection type as a return, then you MUST return empty
> collection object of instead of null. But if you expect POJO as a return,
> then it would be better to return null instead of empty object. Because if
> it returns empty object instead of null, then some one get misunderstand
> who is going to use that API and will try to consume that as expected
> output. Then there may be more problems. You may not be the only one who
> consume your backend api.
>
>
>
>
> *Harsha Thirimanna*
> Associate Tech Lead; WSO2, Inc.; http://wso2.com
> * *
> *email: **hars...@wso2.com* * cell: +94 71 5186770 *
> *twitter: **http://twitter.com/ *
> *harshathirimannlinked-in: **http:
> **//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
> *
>
> *Lean . Enterprise . Middleware*
>
>
> On Wed, Jul 13, 2016 at 12:42 AM, Rasika Perera  wrote:
>
>> ​Hi Sabra
>> ​
>> ​,
>>
>> I think you need to handle this error at jaggery level.​
>>
>> Considering a method returning a user object the client code should not
>>> be able to proceed further if there is no user.
>>
>> ​In this case, -1 for returning NULL. When there is an error,
>> unless
>> ​ it is recoverable locally you ​
>> *should*
>> ​ convey ​it to the upper layers. In your case, If you cannot return a
>> user object it is more intuitive to return an exception such as
>> UserManagerException.
>>
>> By returning NULL, you cannot make it mandatory to handle exception. Your
>> client code will not be aware of NULL unless the developer reads your
>> implementation class OR the documentation. Try to avoid
>> NullPointerException
>> ​ as much as possible.​
>>
>> In your client code(Jaggery) you can catch this error with try{ }
>> catch(error){ }. Found this blogpost [1] which discusses on jaggery error
>> handling.
>> AFAIK Jaggery will wrap java exceptions with ScriptException object.
>>
>> Regards,
>> Rasika
>>
>> [1]
>> http://ruchirawageesha.blogspot.com/2013/04/error-handling-in-jaggery.html
>>
>> On Tue, Jul 12, 2016 at 2:17 PM, Abimaran Kugathasan 
>> wrote:
>>
>>> There are good enough discussion in Stackoverflow [1], [2] and [3]. You
>>> could return null, empty object or throw exception in the case of data not
>>> available.
>>>
>>> It's also depends on the type of the Object you are supposed to return,
>>> if it's a ArrayList/Map, then returning empty ArrayList/Map is better than
>>> returning null, but, in case of Model object, I think, returning null is
>>> better than retuning a mock object of that class.
>>>
>>>
>>> [1] :
>>> http://programmers.stackexchange.com/questions/120355/is-it-better-to-return-null-or-empty-values-from-functions-methods-where-the-ret
>>> [2] :
>>> http://stackoverflow.com/questions/1626597/should-functions-return-null-or-an-empty-object
>>> [3] :
>>> http://programmers.stackexchange.com/questions/228287/returning-null-or-a-empty-value-throw-exception
>>>
>>> On Tue, Jul 12, 2016 at 12:03 PM, Jayanga Kaushalya 
>>> wrote:
>>>
 Hi,

 In my opinion, returning an empty object is far better. It will reduce
 unnecessary null checks and will stop the code from going on different
 paths. And code quality wise also I think returning empty is cleaner.
 For example:

 *List list = getList();*

 *for (Item item : list) {// Do logic.*
 *// This will not execute if the list is empty.*
 *}*

 Is much cleaner than

 *List list = getList();*
 *if (list == null) {*
 *// Handle the logic.*
 *// Now this is a different code path.*
 *}*

 Thanks!

 *Jayanga Kaushalya*
 Software Engineer
 Mobile: +94777860160
 WSO2 Inc. | http://wso2.com
 lean.enterprise.middleware

 On Tue, Jul 12, 2016 at 10:05 

Re: [Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Harsha Thirimanna]

HI Sabra,

If there is collection type as a return, then you MUST return empty
collection object of instead of null. But if you expect POJO as a return,
then it would be better to return null instead of empty object. Because if
it returns empty object instead of null, then some one get misunderstand
who is going to use that API and will try to consume that as expected
output. Then there may be more problems. You may not be the only one who
consume your backend api.




*Harsha Thirimanna*
Associate Tech Lead; WSO2, Inc.; http://wso2.com
* *
*email: **hars...@wso2.com* * cell: +94 71 5186770 *
*twitter: **http://twitter.com/ *
*harshathirimannlinked-in: **http:
**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
*

*Lean . Enterprise . Middleware*


On Wed, Jul 13, 2016 at 12:42 AM, Rasika Perera  wrote:

> ​Hi Sabra
> ​
> ​,
>
> I think you need to handle this error at jaggery level.​
>
> Considering a method returning a user object the client code should not be
>> able to proceed further if there is no user.
>
> ​In this case, -1 for returning NULL. When there is an error,
> unless
> ​ it is recoverable locally you ​
> *should*
> ​ convey ​it to the upper layers. In your case, If you cannot return a
> user object it is more intuitive to return an exception such as
> UserManagerException.
>
> By returning NULL, you cannot make it mandatory to handle exception. Your
> client code will not be aware of NULL unless the developer reads your
> implementation class OR the documentation. Try to avoid
> NullPointerException
> ​ as much as possible.​
>
> In your client code(Jaggery) you can catch this error with try{ }
> catch(error){ }. Found this blogpost [1] which discusses on jaggery error
> handling.
> AFAIK Jaggery will wrap java exceptions with ScriptException object.
>
> Regards,
> Rasika
>
> [1]
> http://ruchirawageesha.blogspot.com/2013/04/error-handling-in-jaggery.html
>
> On Tue, Jul 12, 2016 at 2:17 PM, Abimaran Kugathasan 
> wrote:
>
>> There are good enough discussion in Stackoverflow [1], [2] and [3]. You
>> could return null, empty object or throw exception in the case of data not
>> available.
>>
>> It's also depends on the type of the Object you are supposed to return,
>> if it's a ArrayList/Map, then returning empty ArrayList/Map is better than
>> returning null, but, in case of Model object, I think, returning null is
>> better than retuning a mock object of that class.
>>
>>
>> [1] :
>> http://programmers.stackexchange.com/questions/120355/is-it-better-to-return-null-or-empty-values-from-functions-methods-where-the-ret
>> [2] :
>> http://stackoverflow.com/questions/1626597/should-functions-return-null-or-an-empty-object
>> [3] :
>> http://programmers.stackexchange.com/questions/228287/returning-null-or-a-empty-value-throw-exception
>>
>> On Tue, Jul 12, 2016 at 12:03 PM, Jayanga Kaushalya 
>> wrote:
>>
>>> Hi,
>>>
>>> In my opinion, returning an empty object is far better. It will reduce
>>> unnecessary null checks and will stop the code from going on different
>>> paths. And code quality wise also I think returning empty is cleaner.
>>> For example:
>>>
>>> *List list = getList();*
>>>
>>> *for (Item item : list) {// Do logic.*
>>> *// This will not execute if the list is empty.*
>>> *}*
>>>
>>> Is much cleaner than
>>>
>>> *List list = getList();*
>>> *if (list == null) {*
>>> *// Handle the logic.*
>>> *// Now this is a different code path.*
>>> *}*
>>>
>>> Thanks!
>>>
>>> *Jayanga Kaushalya*
>>> Software Engineer
>>> Mobile: +94777860160
>>> WSO2 Inc. | http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> On Tue, Jul 12, 2016 at 10:05 AM, Sabra Ossen  wrote:
>>>
 Hi Chamila,

 I checked from findbugs and it didn't return an error. Is returning an
 empty object a practice followed in WSO2?

 On Tue, Jul 12, 2016 at 9:25 AM, Chamila Wijayarathna <
 cdwijayarat...@gmail.com> wrote:

> Hi Sabra,
>
> AFAIK when we return a null from a method, find bugs show it as an
> error (please check this) and to fix this we use empty objects. So I think
> the returning null is not something we should do.
>
> Thank You!
>



 --
 *Sabra Ossen*
 *Software Engineer*
 Email: sa...@wso2.com
 Mobile: +94 767 837356

 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Thanks
>> Abimaran Kugathasan
>> Senior Software Engineer
>>
>> Email : abima...@wso2.com
>> Mobile : +94 773922820
>>
>> 

Re: [Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Rasika Perera]

​Hi Sabra
​
​,

I think you need to handle this error at jaggery level.​

Considering a method returning a user object the client code should not be
> able to proceed further if there is no user.

​In this case, -1 for returning NULL. When there is an error,
unless
​ it is recoverable locally you ​
*should*
​ convey ​it to the upper layers. In your case, If you cannot return a user
object it is more intuitive to return an exception such as
UserManagerException.

By returning NULL, you cannot make it mandatory to handle exception. Your
client code will not be aware of NULL unless the developer reads your
implementation class OR the documentation. Try to avoid
NullPointerException
​ as much as possible.​

In your client code(Jaggery) you can catch this error with try{ }
catch(error){ }. Found this blogpost [1] which discusses on jaggery error
handling.
AFAIK Jaggery will wrap java exceptions with ScriptException object.

Regards,
Rasika

[1]
http://ruchirawageesha.blogspot.com/2013/04/error-handling-in-jaggery.html

On Tue, Jul 12, 2016 at 2:17 PM, Abimaran Kugathasan 
wrote:

> There are good enough discussion in Stackoverflow [1], [2] and [3]. You
> could return null, empty object or throw exception in the case of data not
> available.
>
> It's also depends on the type of the Object you are supposed to return, if
> it's a ArrayList/Map, then returning empty ArrayList/Map is better than
> returning null, but, in case of Model object, I think, returning null is
> better than retuning a mock object of that class.
>
>
> [1] :
> http://programmers.stackexchange.com/questions/120355/is-it-better-to-return-null-or-empty-values-from-functions-methods-where-the-ret
> [2] :
> http://stackoverflow.com/questions/1626597/should-functions-return-null-or-an-empty-object
> [3] :
> http://programmers.stackexchange.com/questions/228287/returning-null-or-a-empty-value-throw-exception
>
> On Tue, Jul 12, 2016 at 12:03 PM, Jayanga Kaushalya 
> wrote:
>
>> Hi,
>>
>> In my opinion, returning an empty object is far better. It will reduce
>> unnecessary null checks and will stop the code from going on different
>> paths. And code quality wise also I think returning empty is cleaner.
>> For example:
>>
>> *List list = getList();*
>>
>> *for (Item item : list) {// Do logic.*
>> *// This will not execute if the list is empty.*
>> *}*
>>
>> Is much cleaner than
>>
>> *List list = getList();*
>> *if (list == null) {*
>> *// Handle the logic.*
>> *// Now this is a different code path.*
>> *}*
>>
>> Thanks!
>>
>> *Jayanga Kaushalya*
>> Software Engineer
>> Mobile: +94777860160
>> WSO2 Inc. | http://wso2.com
>> lean.enterprise.middleware
>>
>> On Tue, Jul 12, 2016 at 10:05 AM, Sabra Ossen  wrote:
>>
>>> Hi Chamila,
>>>
>>> I checked from findbugs and it didn't return an error. Is returning an
>>> empty object a practice followed in WSO2?
>>>
>>> On Tue, Jul 12, 2016 at 9:25 AM, Chamila Wijayarathna <
>>> cdwijayarat...@gmail.com> wrote:
>>>
 Hi Sabra,

 AFAIK when we return a null from a method, find bugs show it as an
 error (please check this) and to fix this we use empty objects. So I think
 the returning null is not something we should do.

 Thank You!

>>>
>>>
>>>
>>> --
>>> *Sabra Ossen*
>>> *Software Engineer*
>>> Email: sa...@wso2.com
>>> Mobile: +94 767 837356
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thanks
> Abimaran Kugathasan
> Senior Software Engineer
>
> Email : abima...@wso2.com
> Mobile : +94 773922820
>
> 
> 
>   
> 
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
With Regards,

*Rasika Perera*
Software Engineer
M: +94 71 680 9060 E: rasi...@wso2.com
LinkedIn: http://lk.linkedin.com/in/rasika90

WSO2 Inc. www.wso2.com
lean.enterprise.middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Abimaran Kugathasan]

There are good enough discussion in Stackoverflow [1], [2] and [3]. You
could return null, empty object or throw exception in the case of data not
available.

It's also depends on the type of the Object you are supposed to return, if
it's a ArrayList/Map, then returning empty ArrayList/Map is better than
returning null, but, in case of Model object, I think, returning null is
better than retuning a mock object of that class.


[1] :
http://programmers.stackexchange.com/questions/120355/is-it-better-to-return-null-or-empty-values-from-functions-methods-where-the-ret
[2] :
http://stackoverflow.com/questions/1626597/should-functions-return-null-or-an-empty-object
[3] :
http://programmers.stackexchange.com/questions/228287/returning-null-or-a-empty-value-throw-exception

On Tue, Jul 12, 2016 at 12:03 PM, Jayanga Kaushalya 
wrote:

> Hi,
>
> In my opinion, returning an empty object is far better. It will reduce
> unnecessary null checks and will stop the code from going on different
> paths. And code quality wise also I think returning empty is cleaner.
> For example:
>
> *List list = getList();*
>
> *for (Item item : list) {// Do logic.*
> *// This will not execute if the list is empty.*
> *}*
>
> Is much cleaner than
>
> *List list = getList();*
> *if (list == null) {*
> *// Handle the logic.*
> *// Now this is a different code path.*
> *}*
>
> Thanks!
>
> *Jayanga Kaushalya*
> Software Engineer
> Mobile: +94777860160
> WSO2 Inc. | http://wso2.com
> lean.enterprise.middleware
>
> On Tue, Jul 12, 2016 at 10:05 AM, Sabra Ossen  wrote:
>
>> Hi Chamila,
>>
>> I checked from findbugs and it didn't return an error. Is returning an
>> empty object a practice followed in WSO2?
>>
>> On Tue, Jul 12, 2016 at 9:25 AM, Chamila Wijayarathna <
>> cdwijayarat...@gmail.com> wrote:
>>
>>> Hi Sabra,
>>>
>>> AFAIK when we return a null from a method, find bugs show it as an error
>>> (please check this) and to fix this we use empty objects. So I think the
>>> returning null is not something we should do.
>>>
>>> Thank You!
>>>
>>
>>
>>
>> --
>> *Sabra Ossen*
>> *Software Engineer*
>> Email: sa...@wso2.com
>> Mobile: +94 767 837356
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Thanks
Abimaran Kugathasan
Senior Software Engineer

Email : abima...@wso2.com
Mobile : +94 773922820


  
  
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Jayanga Kaushalya]

Hi,

In my opinion, returning an empty object is far better. It will reduce
unnecessary null checks and will stop the code from going on different
paths. And code quality wise also I think returning empty is cleaner.
For example:

*List list = getList();*

*for (Item item : list) {// Do logic.*
*// This will not execute if the list is empty.*
*}*

Is much cleaner than

*List list = getList();*
*if (list == null) {*
*// Handle the logic.*
*// Now this is a different code path.*
*}*

Thanks!

*Jayanga Kaushalya*
Software Engineer
Mobile: +94777860160
WSO2 Inc. | http://wso2.com
lean.enterprise.middleware

On Tue, Jul 12, 2016 at 10:05 AM, Sabra Ossen  wrote:

> Hi Chamila,
>
> I checked from findbugs and it didn't return an error. Is returning an
> empty object a practice followed in WSO2?
>
> On Tue, Jul 12, 2016 at 9:25 AM, Chamila Wijayarathna <
> cdwijayarat...@gmail.com> wrote:
>
>> Hi Sabra,
>>
>> AFAIK when we return a null from a method, find bugs show it as an error
>> (please check this) and to fix this we use empty objects. So I think the
>> returning null is not something we should do.
>>
>> Thank You!
>>
>
>
>
> --
> *Sabra Ossen*
> *Software Engineer*
> Email: sa...@wso2.com
> Mobile: +94 767 837356
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Sabra Ossen]

Hi Chamila,

I checked from findbugs and it didn't return an error. Is returning an
empty object a practice followed in WSO2?

On Tue, Jul 12, 2016 at 9:25 AM, Chamila Wijayarathna <
cdwijayarat...@gmail.com> wrote:

> Hi Sabra,
>
> AFAIK when we return a null from a method, find bugs show it as an error
> (please check this) and to fix this we use empty objects. So I think the
> returning null is not something we should do.
>
> Thank You!
>



-- 
*Sabra Ossen*
*Software Engineer*
Email: sa...@wso2.com
Mobile: +94 767 837356
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Chamila Wijayarathna]

Hi Sabra,

AFAIK when we return a null from a method, find bugs show it as an error
(please check this) and to fix this we use empty objects. So I think the
returning null is not something we should do.

Thank You!
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Is it best practice to return null or an empty object from a method in DAO layer?

[Sabra Ossen]

Hi All,

Technically speaking "returning null" is the correct thing to do. But by
returning an empty object we can skip the error handling part/null checks
in jaggery code from which the corresponding manager method is called.

Considering a method returning a user object the client code should not be
able to proceed further if there is no user. So IMO returning null and
providing the necessary null checks and error handling should be done.

Any thoughts on $subject and what is the method followed in WSO2? Any other
viewpoints?

Thanks and Regards.

-- 
*Sabra Ossen*
*Software Engineer*
Email: sa...@wso2.com
Mobile: +94 767 837356
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev