Some comments on Stack Overflow question Why doesn\'t the C# compiler stop properties from referring to themselves? regarding warnings got me thinking about old issues that
That looks like a bug to me. I am able to reproduce it on my end in VS2008 SP1.
What is interesting is that it DOES work if it is a reference type, but does not if it is a value type.
The warning will only let you know when a function is going to return Nothing
by default.
You would get a warning if return value was of a reference type.
But your function has a return value of a value type, and those cannot be Nothing
. Therefore, no warning.
This is because function name inside this very function acts as a result variable. You can return a value by assigning it to the function name instead of using Return
. And all variables are initialized with default values, including the function-name variable. This is not the case in C
, hence the different meaning of the warning.
Compare this to using variables before initializing them:
Dim x As Integer
CallFunction(x) 'No warning, x is implicitly and properly initialized to 0.
Dim y as Object
CallFunction(y) 'A warning: variable used before a value is assigned to it
You aren't necessarily asking for a workaround, but I'm just thinking out loud: You could make the return type of the function Nullable.
At runtime, if the function reflects Nothing, you know the programmer didn't explicitly assign a return value. Of course this only works for functions that don't naturally return Nothing. And it's inefficient in many ways.
I just wasted seven hours about the same problem. In my case (using Visual Studio 2012) the compilation ended with a compilation error:
Error MSB3030: File "obj\x86 Debug\<Name of the build target>.exe" could not be copied, because the file was not found. (0, 0)
(The text was translated from the German error message, and I hope it's translated properly.)
Since that message didn't help, I reverted my project back to state where it compiled and finally tracked it down to something similar to the following:
Function SomeFunction() as Boolean
If <somecondition> then
Exit Function
end if
end function
If I replace the exit function with return false or if I insert a SomeFunction = false then the compiler error won't show up.
So yes, as stated before, Visual Basic should default the return value to the default value of the return type, but it somehow crashed the compilation.
I suspect this behaviour is hard to reproduce. My bottom line is: Set return values explicitly. It's clearer to the code and might save you seven hours of debugging.
It's part of the BASIC language. All basic functions have a return type. If you do not specify a return type, then the type is assumed to be object.
So the compiler can't warn you about a missing return, because it doesn't know if you skipped the return intentionally or because you were taking advantage of the default return value feature of the language.
From this http://msdn.microsoft.com/en-us/library/sect4ck6(VS.80).aspx
if you use Exit Function without assigning a value to name, the procedure returns the default value for the data type specified in returntype. If returntype is not specified, the procedure returns Nothing, the default value for Object.