THE USE OF (RETURN) STATMENT IN FUNCTIONS?!

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

What is the use of (return ) statment in functions?
in fact i have got mess with function can't catch it feel lost?
 
Others have given good examples, but let me add one comment.
There are TWO ways to return a value from a function. Both of these will
work:

Function Area(radius as single) as single
'Using the Return statement
Return radius * radius * 3.14159
'Other code here will be ignored
End Function

Function Area(radius as single) as single
'Setting it equal to the name of the function
Area = radius * radius * 3.14159
'Other code here will be executed
End Function

The main difference is that in the first example, the return acts as an EXIT
FUNCTION, and NO code after it will be executed. In the second example, any
additional code after the "FunctionName =" statement WILL be executed.

(Just encountered this in my project. Gee, why aren't any of my SQL
connections closing? Because I was closing the connection objects AFTER I
used the return statement.)
 
BradC said:
The main difference is that in the first example, the return acts as an EXIT
FUNCTION, and NO code after it will be executed. In the second example, any
additional code after the "FunctionName =" statement WILL be executed.

Using the "Return" statement allows you to change the name of your function
without any modification to it's body. And is the preferred method of
returning data. You can overcome the problem described easily by using
Try...Catch...Finally blocks.

~
Jeremy
 
* "Jeremy Cowles said:
Using the "Return" statement allows you to change the name of your function
without any modification to it's body. And is the preferred method of
returning data.

Why? Assigning something to the name of the function and /then/ calling
'Return' followed by the name of the function will work too.
 
Herfried K. Wagner said:
Why? Assigning something to the name of the function and /then/ calling
'Return' followed by the name of the function will work too.


And then if you change the name of the function, your code is broken, unless
you turn Option Explicit Off, and in that case, your probably not worried
about the quality of your code anyway. You say tomatoe, I say tamatoe...
 
Hi Jeremy,

Herfried says probably tomate

He writes only in this newsgroup tomatoe
:-)
Cor
You say tomatoe, I say tamatoe...
 
* "Jeremy Cowles said:
And then if you change the name of the function, your code is broken, unless
you turn Option Explicit Off, and in that case, your probably not worried
about the quality of your code anyway. You say tomatoe, I say tamatoe...

Then all the code calling the function will be broken too. Interfaces
(and methods are part of them) should be "stable", names of methods
should not be changed.
 
Herfried K. Wagner said:
Then all the code calling the function will be broken too. Interfaces
(and methods are part of them) should be "stable", names of methods
should not be changed.

My point is this:

1) at some point, probably many times while refactoring, you *will* change
you function names, its a fact of life.

2) if you can, you should always try to minimize the damage caused by such
changes.

Why would you purposfully add extra work when you dont need to? Saying, "it
will break in other places, so why not add more places for it to break", is
just a sliperly-slope.

But let us end this discussion, because we probably won't ever see
eye-to-eye, and that's ok.

~
Jeremy
 
Back
Top