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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
