• Post Reply Bookmark Topic Watch Topic
  • New Topic

doubt with return  RSS feed

 
miguel lisboa
Ranch Hand
Posts: 1281
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
inside a method, i want to test if a string is what i expect; else, i want the program flow to stop right there. Towards this goal i use the keyword return:


My Q:
does return does, properly, what i intend?
Or there is another, better, way of stopping the program execution?
thanks in advance
[ September 22, 2004: Message edited by: miguel lisboa ]
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By "the program flow to stop right there," do you mean exit out of the program entirely? Or do you simply want that method to exit and have the program continue on with its work?

If the former, you wantwhere <int> is an exit code: 0 means normal program exit; anything else typically means an error occured. It only matters what you pass if some other process is evaluating the return code.
 
miguel lisboa
Ranch Hand
Posts: 1281
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i guess i mean the latter: if my var isnt validated, i dont want it inserted into database - so i want to stop the flow of the processing, not ending the app (i'm doing it with a warning msg dialog); else, its ok going on with insert
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by miguel lisboa:
i guess i mean the latter: if my var isnt validated, i dont want it inserted into database

Then "return" is what you want. You can use it to exit a method even when you are not returning an actual value.
 
miguel lisboa
Ranch Hand
Posts: 1281
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
that's great knowing that, because i checked my two java books (thinking in java and head first java) and coudnt find a proper answer

thanks a lot again
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You will often find a certain disdain for control-flow-altering keywords like return (non-value), break, continue and goto. The weak argument is that you can always replace them with equivalent branching (if-else) mechanisms. I say weak because you could replace a lot of other useful constructs too, but as they say, "Use the right tool for the job."

The other argument is that they invite confusion. I personally find that, used properly, they improve understanding and readability. I've adopted the coding style of "exit early" methods: you attempt to exit from the method as early as possible. Compare these two implementations:I find the second version much easier to read. You don't need to maintain mental state or match ifs and elses to find which failure triggers which exception. It's also far easier to modify to add a new condition later.

That's my two cents, anyway. As to why those books you mentioned don't cover it, perhaps it was implied or the index isn't very thorough.
 
miguel lisboa
Ranch Hand
Posts: 1281
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I find the second version much easier to read

me too!
It's also far easier to modify to add a new condition later.

cant agree more

As to why those books you mentioned don't cover it, perhaps it was implied or the index isn't very thorough.

i'd add: maybe i wasnt able to properly find it...

Excuse me my basic following Qs, but i'm no pro at all, just a plain amateur:
are those 'this' really needed at all?
can one catch some of those exceptions with, lets say, a warning msg dialog?

thanks a lot again
 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It sounds like you are trying to deal with an error situation here. This is a perfect candidate to throw an exception, rather than simply returning. In such a situation, the caller should then decide what action to take.

One advantage to this approach is that you can separate the underlying database logic from the user interface. This will allow you to more easily change the user interface from a GUI to a text console or a Web app.

That's just my 2 cents ;-)

Keep coding!

Layne
 
miguel lisboa
Ranch Hand
Posts: 1281
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
that's great, really
thanks for pointing it!
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by miguel lisboa:
are those 'this' really needed at all?

No, but it's common style to include them to be 100% clear. Where they're necessary is in a standard setter method:Some people prefer to prefix all member variables with _ or m; others prefix their arguments with _ or the (theName); still others rely on the IDE to color the variables (Eclipse) based on the scope.

I used to prefer simply writing clear code and disambiguating the few cases that weren't obvious (or using "this" in setters). The more and more I have to deal with other people's code, the more I am thankful to see the "this."
can one catch some of those exceptions with, lets say, a warning msg dialog?

Absolutely! And as Layne pointed out, it will make your code much more reusable and maintainable. If you throw meaningful exceptions in the worker code (a data-access object for example), then your UI code can catch it and handle it (show an error dialog).

When you want to reuse that same DAO in a command-line or automated tool, you can catch it and print an error -- and exit(1) if severe -- or log a message. If you put the code to display an error dialog in the DAO itself, you're pegged to a GUI app.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!