not all paths return a value

[Guest]

i have inherited the following migrated vb6 code (vb2005)
but i DONT get the "not all paths return a value" squiggly - is this a
'feature' of on error goto?

Private Function CreateFolder(ByVal sFileName As String) As Boolean

On Error GoTo Errors

'Create it if necessary
If Directory.Exists(sFileName) = False Then
Directory.CreateDirectory(sFileName)
End If

'Succeeded in creating a folder
CreateFolder = True

Errors:

End Function

 

[Joergen Bech]

It is recommended that classic VB6 error handling be replaced
with structured exception handling.

But to answer your specific question: In the code, no specific value
is returned in the (empty) error handler.

Just put a "CreateFolder = False" line after the "Errors:" label.

Note: You can also write "Return <value>" instead of
"<function name> = <value>".

/Joergen Bech

 

[John Timney \( MVP \)]

I dont program in VB.NET - but not all paths return a value because falling
into error before you set createFolder=True would fail to provide a return
value, and you need to return a bool.

Put CreateFolder = False in your error section. Better still - start using
try/catch statements and get rid of the goto

 

[Oenone]

I dont program in VB.NET - but not all paths return a value because
falling into error before you set createFolder=True would fail to
provide a return value, and you need to return a bool.

I'm sure he realises that, the question was as to why he *didn't* get a
compiler warning. I would have expected there to be one too.

 

[Guest]

this will definitely be rewritten, my point was the code as it stands does
NOT warn about a code path that does not return a value

 

[Herfried K. Wagner [MVP]]

i have inherited the following migrated vb6 code (vb2005)
but i DONT get the "not all paths return a value" squiggly - is this a
'feature' of on error goto?

Private Function CreateFolder(ByVal sFileName As String) As Boolean

On Error GoTo Errors

'Create it if necessary
If Directory.Exists(sFileName) = False Then
Directory.CreateDirectory(sFileName)
End If

'Succeeded in creating a folder
CreateFolder = True

Errors:

End Function

To me it seems that they have forgotten to implement the check for 'On Error
GoTo'...

 

[Joergen Bech]

Whoops. Misread the original post. .Net Reflector to the rescue.

This is what the code is turned into:

---snip---
Private Shared Function CreateFolder(ByVal sFileName As String) As
Boolean
Dim flag1 As Boolean
Dim num2 As Integer
Try
ProjectData.ClearProjectError
Dim num1 As Integer = 2
If Not Directory.Exists(sFileName) Then
Directory.CreateDirectory(sFileName)
End If
flag1 = True
goto Label_0066
Label_0025:
num2 = -1
Select Case num1
Case 0, 1
goto Label_005B
Case 2
goto Label_0066
End Select
Catch obj1 As Object When (?)
ProjectData.SetProjectError(CType(obj1, Exception))
goto Label_0025
End Try
Label_005B:
Throw ProjectData.CreateProjectError(-2146828237)
Label_0066:
If (num2 <> 0) Then
ProjectData.ClearProjectError
End If
Return flag1
End Function
---snip---

Dim flag1 As Boolean means that flag1 is implicitly initialized
to False by .Net.

So all code paths are indeed satisfied.

But it sure is ugly.

Regards,

Joergen Bech

 

[m.posseth]

well it does return a value cause it returns false
as a boolean datatype can`t be nothing or empty



so what is the point ??

M. Posseth [MCP]

 

[Joergen Bech]

To me it seems that they have forgotten to implement the check for 'On Error
GoTo'...

As far as I understand it, the squiggly lines are not based on the
source text you see, but what the parser turns it into. Which in this
case is an entirely different beast. See my other post.

I see no bugs.

/JB

 

[Joergen Bech]

His point is that - on the surface - it does not *explicitly*
return a value.

/JB

well it does return a value cause it returns false
as a boolean datatype can`t be nothing or empty



so what is the point ??

M. Posseth [MCP]

this will definitely be rewritten, my point was the code as it stands does
NOT warn about a code path that does not return a value

 

[Patrice]

Looks like a normal behavior as all paths are likely returning a value as
all paths are ending with end function (and the implicit return value is
false). IMO you have rather this warning when you use the "exit function"
statement ??

 

[Patrice]

A value is still returned even if not explicit so Im' not sure the warning
would be fine here. Let's take the other way round. What kind of code would
create this warning ? (Exit Function ?)

--
Patrice

His point is that - on the surface - it does not *explicitly*
return a value.

/JB

well it does return a value cause it returns false
as a boolean datatype can`t be nothing or empty



so what is the point ??

M. Posseth [MCP]

this will definitely be rewritten, my point was the code as it stands does
NOT warn about a code path that does not return a value

:

I dont program in VB.NET - but not all paths return a value because
falling
into error before you set createFolder=True would fail to provide a
return
value, and you need to return a bool.

Put CreateFolder = False in your error section. Better still - start
using
try/catch statements and get rid of the goto
--
Regards

John Timney
Microsoft MVP

i have inherited the following migrated vb6 code (vb2005)
but i DONT get the "not all paths return a value" squiggly - is this a
'feature' of on error goto?

Private Function CreateFolder(ByVal sFileName As String) As Boolean

On Error GoTo Errors

'Create it if necessary
If Directory.Exists(sFileName) = False Then
Directory.CreateDirectory(sFileName)
End If

'Succeeded in creating a folder
CreateFolder = True

Errors:

End Function

 

[Ken Halter]

i have inherited the following migrated vb6 code (vb2005)
but i DONT get the "not all paths return a value" squiggly - is this a
'feature' of on error goto?

Errors:

End Function

I've read a few of these answers that state something along the lines of:

That should never be required. Since False is the default return value for
any boolean function/variable/whatever, explicitly setting the return =
False should never be required. If it is suddenly required after 30 years of
programming, there should be a huge notice posted on the web somewhere that
says "forget about your existing source code, everything has suddenly
changed for no good reason"

 

[Herfried K. Wagner [MVP]]

As far as I understand it, the squiggly lines are not based on the
source text you see, but what the parser turns it into. Which in this
case is an entirely different beast. See my other post.

The occurance of the warning depends on the return type of the function. So
it's not actually a bug, but I believe the warning could have been
implemented in a way that it is also shown for functions which return a
value type.

 

[Herfried K. Wagner [MVP]]

Looks like a normal behavior as all paths are likely returning a value as
all paths are ending with end function (and the implicit return value is
false). IMO you have rather this warning when you use the "exit function"
statement ??

Consider this sample:

\\\
Public Function Foo() As Object
If True Then
Return "x"
End If
End Function
///

This function implicitly returns 'Nothing' on all code paths too if no
return value is set. So I do not think that this is a big difference to the
scenario the OP described, although the warning is shown for the code above.

 

[Herfried K. Wagner [MVP]]

Ken,

I've read a few of these answers that state something along the lines of:


That should never be required. Since False is the default return value for
any boolean function/variable/whatever, explicitly setting the return =
False should never be required. If it is suddenly required after 30 years
of programming, there should be a huge notice posted on the web somewhere
that says "forget about your existing source code, everything has suddenly
changed for no good reason"

You could actually disable the warning. Simply open up the project file in
a text editor and add the warning number (42105) to the 'NoWarn' element.
My main concern is that the warning only occurs at functions which return a
reference type.

The full text of the warning makes this more clear: "[...] A null reference
exception could occur at run time when the result is used". I do not think
that implicitly returning 'Nothing' is a big problem. The main problem is
IMO forgetting to set a return value for a certain code path inside the
function. The same problem applies to BC42104 too. I have summed up my
thoughts on the usefulness of this warning in an article (in German):

Zur Sinnhaftigkeit der Compilerwarnung BC42104
<URL:http://dotnet.mvps.org/dotnet/articles/bc42104/>

 

[Patrice]

Sorry I don"t have 2005 hand. Even with a boolean return value ? What is the
code create for this ? I wonder what is the exact condition that triggres
this warning...

 

[Herfried K. Wagner [MVP]]

Sorry I don"t have 2005 hand. Even with a boolean return value ? What is
the
code create for this ? I wonder what is the exact condition that triggres
this warning...

The warning will only work if the function's return type is a reference
type.

 

[Patrice]

Thanks for the follow up...

--
Patrice

The warning will only work if the function's return type is a reference
type.

 

[Joergen Bech]

The occurance of the warning depends on the return type of the function. So
it's not actually a bug, but I believe the warning could have been
implemented in a way that it is also shown for functions which return a
value type.

Care to give me an example that involves On Error Goto?

It is true that the squiggly lines appear for

Public Function ObjectDoesProduceSquiggleLines() As Object
'Do nothing
End Function

but not for

Public Function ValueProducesNoSquiggleLines() As Boolean
Dim b As Boolean = True
End Function

But when the "On Error ..." abomination is used, as in the sample
the original poster provided ...

Check the samples below. None of them produce squiggly lines, even
though I am fairly positive that they cover both objects and value
types as return values. I see no difference in behavior due to
the choice of return types.

If you look at what the compiler turns the samples into, you will
see that something is explicitly returned on all code paths in all
samples.

---snip---
Option Explicit On
Option Strict On
....
Public Function GetString() As String
On Error GoTo someerror
Return ""
SomeError:
End Function

Public Function GetObject() As Object
On Error GoTo SomeError
Return Nothing
SomeError:
End Function

Public Function GetBoolean() As Boolean
On Error GoTo SomeError
Return False
SomeError:
End Function

Public Function GetArrayList() As ArrayList
On Error GoTo SomeError
Return New ArrayList
SomeError:
End Function
---snip---

Regards,

Joergen Bech