I have a very simple function I'm working on.

Function CarSpeed(ByVal kph As Integer)
If kph < 0 Then
_quote = "the car is in reverse"
_actualspeed = kph
ElseIf kph = 0 Then
_quote = "the car is parked."
_actualspeed = kph
ElseIf kph > 0 And kph <= 10 Then
_quote = "the car is moving slowly."
_actualspeed = kph
Else
_quote = "the car is moving quickly."
_actualspeed = kph
End If

'New for VS 2005 apparently...
Return kph

End Function

Originally, I built this using Visual Studio .NET 2003. I just downloaded
the Visual Studio .NET 2005 express and when I initially typed in the old
code I didn't have the line "Return kph" on the original version, and I got a
warning saying, "Function CarSpeed doesn't return a value on all code paths.
A null reference exception could occur at run time when the result is used."

So why do I need to include the line "Return kph" for VS 2005?

Military Smurf wrote:
[..]
>
> End Function
>
> Originally, I built this using Visual Studio .NET 2003. I just downloaded
> the Visual Studio .NET 2005 express and when I initially typed in the old
> code I didn't have the line "Return kph" on the original version, and I got a
> warning saying, "Function CarSpeed doesn't return a value on all code paths.
> A null reference exception could occur at run time when the result is used."
>
> So why do I need to include the line "Return kph" for VS 2005?

Since you don't explicitly declare a type, this function returns an
Object.

If a function that returns an Object never sets its return value
(either by the older FunctionName= syntax or with Return), then it will
return a null reference. Callers attempting to do anything with the
return value of the function will then most likely cause a null
reference exception.

VS2005 notices this and therefore suggests that the return value not be
Nothing, which your Return statement duly does.

That's the simple facts, now the commentary:

- VS2003 with Option Strict On doesn't like your original code, which
tells me you are running without Option Strict On - you may want to
consider making this an absolute standard in the future. The time for
additional typing sometimes required is more than compensated by the
debugging time savings produced by working with strongly-typed code.

- It's bad style to have 'side effects' in procedures, and worse to
have functions that consist _only_ of side effects! A call to this
function should be replaced with something like

_actualspeed = kph
_quote = DescribeSpeed(kph)

where DescribeSpeed takes an Integer and returns a String.

"Larry Lard" wrote:

[..]
> _actualspeed = kph
> _quote = DescribeSpeed(kph)
>
> where DescribeSpeed takes an Integer and returns a String.
>
> --
> Larry Lard
> Replies to group please
>
Thanks for that, and while I understand a lot of what you are saying, what
are these "side effects" I need to be aware of?

If you didn't have the Return statement in your function before, I
presume that you were not calling it as a function. In that case, you
should make the method a Sub instead of a function.

"Military Smurf" <MilitarySmurf> schrieb:
[..]
> End Function
>
> Originally, I built this using Visual Studio .NET 2003. I just downloaded
> the Visual Studio .NET 2005 express and when I initially typed in the old
> code I didn't have the line "Return kph" on the original version, and I
> got a
> warning saying, "Function CarSpeed doesn't return a value on all code
> paths.
> A null reference exception could occur at run time when the result is
> used."

Use 'Sub' instead of 'Function' if 'CarSpeed' is not intended to return a
value.

As addition to Herfried because he obvious missed that.

to make it even less troubleful use "AndAlso" instead of "And"

Cor

"Herfried K. Wagner [MVP]" <hirf-spam-me-here> schreef in bericht
news:a916
[..]

if andalso orelse = new to you then

read the The Ballad of AndAlso and OrElse

http://www.panopticoncentral.net/arc...08/18/179.aspx

end if

:-)

Michel Posseth [MCP]


"Cor Ligthert [MVP]" <notmyfirstname> schreef in bericht
news:a648
[..]

Military Smurf wrote:
> "Larry Lard" wrote:
> > - It's bad style to have 'side effects' in procedures, and worse to
> > have functions that consist _only_ of side effects! A call to this
> > function should be replaced with something like
> >
> > _actualspeed = kph
> > _quote = DescribeSpeed(kph)
> >
> > where DescribeSpeed takes an Integer and returns a String.
>
> Thanks for that, and while I understand a lot of what you are saying, what
> are these "side effects" I need to be aware of?

You can read more about side effects here:
<http://en.wikipedia.org/wiki/Side-effect_%28computer_science%29> but
in short, a side effect is when a function changes something that it
isn't obvious that it changes, typically a variable at some broader
scope. An example:

'module level
Dim a as integer

Function Negate(n as integer) as integer
Return -n
End Function

Function NegateWithSideEffect(n as integer) as integer
a = a + 1
Return -n
End Function

Sub Example()
Dim b as integer
b = 3
b = Negate(b)
'now b = -3 and no surprises

a = 2
b = NegateWithSideEffect(b)
'now b = 3 as expected
'BUT a has also changed!
End Sub

In this example, there is nothing to tell a caller of
NegateWithSideEffect that calling this function will also change a.
Real world examples don't have such 'giveaway' names! :)

There's a guideline for coding called the Principle of Least
Astonishment (more at
<http://en.wikipedia.org/wiki/Principle_of_least_astonishment>) which
basically says: don't do anything surprising. In this example changing
a might well come as a surprise, and an unpleasant one, to an unwitting
user of NegateWithSideEffect.

Like all guidelines and principles, how rigorously to stick to them
depends on a number of factors - throwaway programs for personal
consumption, you can get away with anything you like; flying a space
shuttle, get ten people to check every line. But in general it is
better to get into the habit of doing things 'the right way', so that
everything one does is better than it needs to be.