THE USE OF (RETURN) STATMENT IN FUNCTIONS?!

[Guest]

What is the use of (return ) statment in functions?
in fact i have got mess with function can't catch it feel lost?

 

[Al Williams]

To "return" the result of the function back to the calling code ...

 

[Cor]

LOL

Nice one

 

[BradC]

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.)

 

[Jeremy Cowles]

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

 

[Herfried K. Wagner [MVP]]

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.

 

[Jeremy Cowles]

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...

 

[Cor]

Hi Jeremy,

Herfried says probably tomate

He writes only in this newsgroup tomatoe

Cor
You say tomatoe, I say tamatoe...

 

[Herfried K. Wagner [MVP]]

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 [MVP]]

Herfried says probably tomate

In German: "Tomate", in Austrian: "Paradeis".

SCNR

 

[Jeremy Cowles]

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