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 <[email protected]> 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 <[email protected]> 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 <https://en.wikipedia.org/wiki/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 >> <http://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html#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 <[email protected]> wrote: >> >>> >>> >>> On Sun, Jul 17, 2016 at 2:53 PM, Nuwan Pallewela <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> On Wed, Jul 13, 2016 at 10:15 AM, Sabra Ossen <[email protected]> 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 <[email protected]> >>>>> 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 >>>>>> * <http://www.apache.org/>* >>>>>> *email: **[email protected]* <[email protected]>* cell: +94 71 5186770 * >>>>>> *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>* >>>>>> *harshathirimannlinked-in: **http: >>>>>> <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122 >>>>>> <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>* >>>>>> >>>>>> *Lean . Enterprise . Middleware* >>>>>> >>>>>> >>>>>> On Wed, Jul 13, 2016 at 12:42 AM, Rasika Perera <[email protected]> >>>>>> 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 < >>>>>>> [email protected]> 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 < >>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>> 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 < >>>>>>>>>> [email protected]> 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: [email protected] >>>>>>>>>> Mobile: +94 767 837356 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Dev mailing list >>>>>>>>>> [email protected] >>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks >>>>>>>> Abimaran Kugathasan >>>>>>>> Senior Software Engineer >>>>>>>> >>>>>>>> Email : [email protected] >>>>>>>> Mobile : +94 773922820 >>>>>>>> >>>>>>>> <http://stackoverflow.com/users/515034> >>>>>>>> <http://lk.linkedin.com/in/abimaran> >>>>>>>> <http://www.lkabimaran.blogspot.com/> >>>>>>>> <https://github.com/abimarank> <https://twitter.com/abimaran> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> [email protected] >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> With Regards, >>>>>>> >>>>>>> *Rasika Perera* >>>>>>> Software Engineer >>>>>>> M: +94 71 680 9060 E: [email protected] >>>>>>> LinkedIn: http://lk.linkedin.com/in/rasika90 >>>>>>> >>>>>>> WSO2 Inc. www.wso2.com >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> [email protected] >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Sabra Ossen* >>>>> *Software Engineer* >>>>> Email: [email protected] >>>>> Mobile: +94 767 837356 >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> Thanks, >>>> Nuwan >>>> >>>> -- >>>> ---------------------------------------------------------- >>>> >>>> *Nuwan Chamara Pallewela* >>>> >>>> >>>> *Software Engineer* >>>> >>>> *WSO2, Inc. *http://wso2.com >>>> *lean . enterprise . middleware* >>>> >>>> Email *[email protected] <[email protected]>* >>>> Mobile *+94719079739 <%2B94719079739>@* >>>> >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> >>> Udara Liyanage >>> Software Engineer >>> WSO2, Inc.: http://wso2.com >>> lean. enterprise. middleware >>> >>> Blog: http://udaraliyanage.wordpress.com >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> With Regards, >> >> *Rasika Perera* >> Software Engineer >> LinkedIn: http://lk.linkedin.com/in/rasika90 >> >> [image: wso2-signature-general.png] <https://wso2.com/signature> >> >> WSO2 Inc. www.wso2.com >> lean.enterprise.middleware >> > > > > -- > > Udara Liyanage > Software Engineer > WSO2, Inc.: http://wso2.com > lean. enterprise. middleware > > Blog: http://udaraliyanage.wordpress.com > -- ---------------------------------------------------------- *Nuwan Chamara Pallewela* *Software Engineer* *WSO2, Inc. *http://wso2.com *lean . enterprise . middleware* Email *[email protected] <[email protected]>* Mobile *+94719079739@*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
