I don't like this behavior - implicitly returning value types

  • Thread starter Thread starter rowe_newsgroups
  • Start date Start date
R

rowe_newsgroups

I just noticed this about value types and return values, and it kind
of bugs me that the compiler won't treat it as an error, even with
Option Strict On.

Try this out:

Option Strict On

Public Class MyClass

Private Sub ExtractionSettings_Load(ByVal sender As
System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
MsgBox(MyProp.ToString())
End Sub

ReadOnly Property MyProp() As Int16
Get

End Get
End Property

End Class

This will compile and run perfectly fine (if I typed it right :-) ),
always showing 0 in the opening messagebox. I really wish that the IDE
would tell me that I didn't explicitly specify a return value for
MyProp. (Yes, I know it's a value type and therefore it has a value of
0 at instantiation so it is returning a value, and thus not violating
the return value rules).

Is there a setting I missed somewhere that I could use to flag this as
an error?

Thanks,

Seth Rowe
 
I just noticed this about value types and return values, and it kind
of bugs me that the compiler won't treat it as an error, even with
Option Strict On.

Try this out:

Option Strict On

Public Class MyClass

Private Sub ExtractionSettings_Load(ByVal sender As
System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
MsgBox(MyProp.ToString())
End Sub

ReadOnly Property MyProp() As Int16
Get

End Get
End Property

End Class

This will compile and run perfectly fine (if I typed it right :-) ),
always showing 0 in the opening messagebox. I really wish that the IDE
would tell me that I didn't explicitly specify a return value for
MyProp. (Yes, I know it's a value type and therefore it has a value of
0 at instantiation so it is returning a value, and thus not violating
the return value rules).

Is there a setting I missed somewhere that I could use to flag this as
an error?

Thanks,

Seth Rowe
Click to expand...

Yeah I've noticed this too... I forget a return in a Get and I was
tired so I didn't notice for half an hour... I thought I was going
crazy ("WTF is there no value in that control?!?!') until I saw that
mistake... I just sorta grumbled and added the missing return.
 
I just noticed this about value types and return values, and it kind
of bugs me that the compiler won't treat it as an error, even with
Option Strict On.

Try this out:

Option Strict On

Public Class MyClass

Private Sub ExtractionSettings_Load(ByVal sender As
System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
MsgBox(MyProp.ToString())
End Sub

ReadOnly Property MyProp() As Int16
Get

End Get
End Property

End Class

This will compile and run perfectly fine (if I typed it right :-) ),
always showing 0 in the opening messagebox. I really wish that the IDE
would tell me that I didn't explicitly specify a return value for
MyProp. (Yes, I know it's a value type and therefore it has a value of
0 at instantiation so it is returning a value, and thus not violating
the return value rules).

Is there a setting I missed somewhere that I could use to flag this as
an error?

Thanks,

Seth Rowe
Click to expand...

I agree with you Seth, that this is bad behavior. There is no way to
"turn it off" that I know of. This, IMHO, is the result of trying to
stay compatabile with VB.CLASSIC. VB has always returned it's values
from functions/properties via assigning to the function name - if you
didn't assign then it returned the default value.
 
I agree with you Seth, that this is bad behavior. There is no way to
"turn it off" that I know of. This, IMHO, is the result of trying to
stay compatabile with VB.CLASSIC. VB has always returned it's values
from functions/properties via assigning to the function name - if you
didn't assign then it returned the default value.
Click to expand...

Perhaps the next version of Visual Basic will insist on explicit Return
statements in property Get routines and will then complain that there's
no value returned on every code path... :-)

(Oh, there I go again; giving Our Friends in Redmond ideas...)

Regards,
Phill W.
 
Perhaps the next version of Visual Basic will insist on explicit Return
statements in property Get routines and will then complain that there's
no value returned on every code path... :-)

(Oh, there I go again; giving Our Friends in Redmond ideas...)

Regards,
Phill W.

Perhaps the next version of Visual Basic will insist on explicit Return
statements in property Get routines and will then complain that there's
no value returned on every code path... :-)
Click to expand...

You mean something like "Option C# Warnings On"

:-)

Thanks,

Seth Rowe
 
I just noticed this about value types and return values, and it kind
of bugs me that the compiler won't treat it as an error, even with
Option Strict On.

Try this out:

Option Strict On

Public Class MyClass

Private Sub ExtractionSettings_Load(ByVal sender As
System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
MsgBox(MyProp.ToString())
End Sub

ReadOnly Property MyProp() As Int16
Get

End Get
End Property

End Class

This will compile and run perfectly fine (if I typed it right :-) ),
always showing 0 in the opening messagebox. I really wish that the IDE
would tell me that I didn't explicitly specify a return value for
MyProp. (Yes, I know it's a value type and therefore it has a value of
0 at instantiation so it is returning a value, and thus not violating
the return value rules).

Is there a setting I missed somewhere that I could use to flag this as
an error?

Thanks,

Seth Rowe
Click to expand...

Seth,

I wonder if it's like that to keep as much compatibility with VB6 as
possible. Though, you'd think a warning would be an acceptable
compromise.

Brian
 
Perhaps the next version of Visual Basic will insist on explicit Return
statements in property Get routines and will then complain that there's
no value returned on every code path... :-)

(Oh, there I go again; giving Our Friends in Redmond ideas...)

Regards,
Phill W.- Hide quoted text -

- Show quoted text -
Click to expand...

Not a bad idea. IMHO, it should just be incorporated into option
strict. That already makes a lot of code not vb.classic compliant
anyway :)
 
Back
Top