• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

return statements from Java

 
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,
Here is a scenario.
I have a set of method calls in a method (which has lot of logic also).
I check a lot of if conditions.
Is it typically better to return if a bad condition is detected, or set the status as bad and return at the end of the method.
Thus, 1 return versus multiple returns is the issue.
Avianu
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you ask ten programmers, you'll probably get ten answers to this question. My own opinion is this: the "one entry/one exit" rule originated in the old days, in languages where it was possible to enter a block of code via multiple routes; the notions of structured programming are now so ingrained in us that we wouldn't even think of being able to jump into the middle of a function, but it was once commonplace. Nowadays, most languages don't even allow it. But once, following this rule made your code clearer. Knowing this rule was being followed made it possible to understand code more easily.
Nowadays, with the "one entry" part of the rule gone, all we've got left is the "one exit" part. Does this make sense by itself? I say no. I think multiple returns from a function are absolutely fine, especially if the alternative is to set "returnFlag," branch on "returnFlag" one or more times and then return; yuk. If you reach a point in a function where you know that no more code should be executed, returning right there is the clearest way to indicate that -- so yes, that's what you should do. Whatever leads to the cleanest, easiest code to understand, is the right thing to do.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Whatever leads to the cleanest, easiest code to understand, is the right thing to do.


Can we make this a standard banner on every page of the Ranch?
bear
[ August 04, 2003: Message edited by: Bear Bibeault ]
 
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I concur with both of you!
 
Bartender
Posts: 1844
Eclipse IDE Ruby Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
NOt that I'm a proponent of it, but the "one exit" concept is supposed to aid in refactoring your code; i.e., it makes it easier to cut-and-paste when you are changing your code. Personally, I am not a fan of the "one exit" concept, although "n-exits" I find are particularily obnoxious to read. As such, I tend to have a 2.5-exit concept:
1 exit at teh beginning of the function. This evaluates whenther or not the function has to run. (Note that theoretically this should be a separate function, but sometimes it doesn't make sense as such...)
This usually is a return statement, but sometimes this should throw a java.lang.IllegalArgumentException, depending on the situation.
1 exit at the end of the function. (I always include a "return;" even when the method's return type is void. One of my idiosyncracities...)
These make the two exits. The extra .5 come from the fact that sometime it is necessary to exit in the middle of a for-loop (or other control structure).
Likewise, I don't understand those that eschew breaks and continues in thier loops. Like my return statements, I usually have these near the beginning of the loops (or the end in the case of the break; it dosen't really make sense to have a continue at the end of your loop--unless you want to be consistant in use of redundant statements, like my return above )
 
Avianu Sud
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Very Good points. I really like the 2.5-return approach.
Its a good middle-road to resilient and clean code.
On a related note, is it always best to check for the input parameters and return either a status or throw a exception? Also, if this exception is unchecked its likely that no one will catch it, and it will end the program, when it could have been handled by someone. This gets into the checked versus unchecked exception discussion. Another topic with lot of perspectives. I personally, prefer checked exceptions(Ones that are application defined), but there seems to be a shift towards runtime exceptions.
I feel that with Runtime exceptions(Again application defined), it is easy for api users to ignore those, leading to less-relilient code.
What do you think?
- Avianu
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic