Whats the difference?

G

Guest

I know that this is just a warning message, but I wonder why the IDE flags
the first function with a warning, but not the second one. The warning
message is :
Function 'GetView' doesn't return a value on all code paths. A null
reference exception could occur at run time when the result is used.
Here is the code:
______________________________________________________________________
Public Class SearchMgr
Public Enum SearchMgrTables
Subscriptions
Contacts
Invoices
End Enum
..
..
..
Public Function GetView(ByVal table As SearchMgrTables, ByVal colname As
String) As DataView
Select Case table
Case SearchMgrTables.Subscriptions
If SubSrchMgr Is Nothing Then
SubSrchMgr = New SubSearchViewMgr
End If
Return SubSrchMgr.GetView(colname)
Case SearchMgrTables.Contacts
If ContactSrchMgr Is Nothing Then
ContactSrchMgr = New ContactSearchViewMgr
End If
Return ContactSrchMgr.GetView(colname)
Case SearchMgrTables.Invoices
If OpenInvSrchMgr Is Nothing Then
OpenInvSrchMgr = New OpenInvSearchViewMgr
End If
Return OpenInvSrchMgr.GetView(colname)
End Select
End Function

Public Function Seek(ByVal table As SearchMgrTables, ByVal val As
String) As Integer
Select Case table
Case SearchMgrTables.Subscriptions
If SubSrchMgr IsNot Nothing Then
Return Search(SubSrchMgr.CurrentView, val,
SubSrchMgr.CurrentColumnNum)
End If
Case SearchMgrTables.Contacts
If ContactSrchMgr IsNot Nothing Then
Return Search(ContactSrchMgr.CurrentView, val,
ContactSrchMgr.CurrentColumnNum)
End If
Case SearchMgrTables.Invoices
If OpenInvSrchMgr IsNot Nothing Then
Return Search(OpenInvSrchMgr.CurrentView, val,
OpenInvSrchMgr.CurrentColumnNum)
End If
End Select
'Throw New ArgumentException("You must select a view before you can
seek.")
End Function

I commented out the "Throw" statement to make the Seek function look
identical to the GetView function. But the IDE only complains about the
GetView function.
Any Ideas?
Terry
 
J

John

Hi Terry,

In your GetView function, if table doesn't match one of the three cases you
have, then the return will be null. Your return is a reference type, which
can be null.

In your Seek function, if table doesn't match one of the three cases you
have, then the return will be zero because it is an Integer. Your return is
a value type in this case.

J
 
G

Guest

Hi John,
Ok, I get it. Too bad its not smart enough to figure out that the select
case was exhaustive.
 
C

Cor Ligthert[MVP]

Terry,

As your case methode does not fulfil any statement in the case, you are not
returning something.
A return after the case select will probably solve this.

Cor
 
G

Guest

Hi Core,
Not sure what you mean by 'does not fulfil any statement in the case'.
There are only 3 possibilities for the 'table' enumerated type and all 3 are
covered by the select statement. There is no other possibility.
 
G

Guest

Terry said:
Hi John,
Ok, I get it. Too bad its not smart enough to figure out that the select
case was exhaustive.

In fact it's not exhaustive. It's possible for an enum to have other
values that the ones that you specified.

You have covered three of the possible values, there are still
4294967293 left to handle before it's exhaustive...
 
G

Guest

Well, since I operate with option strict on, I trhink all cases are covered
unless there is something else I am missing.
 
G

Guest

I do understand your point though. At first I thought I would have to return
something and wasn't quit sure what that should be. But as it turns out, it
is happy with simply adding...
Throw New ArgumentException("Invalid table requested.")
before the end function.
 
J

John

Hi Terry,

I think it would be more clear if you put the ArgumentException
under a Case Else instead of before the end function.

J
 
R

Rory Becker

Thanks John - I will follow your advice.
Another great reason (besides clarity) for always coding an else clause,
is than you cannot typically predict when the enum might be adjusted (by
you or someone else on your team) to have new items which will of course
not be catered to by this and perhaps many other select case statements.
 
G

Guest

Good point - Thanks
--
Terry


Rory Becker said:
Another great reason (besides clarity) for always coding an else clause,
is than you cannot typically predict when the enum might be adjusted (by
you or someone else on your team) to have new items which will of course
not be catered to by this and perhaps many other select case statements.
 
?

=?ISO-8859-1?Q?G=F6ran_Andersson?=

Rory said:
Another great reason (besides clarity) for always coding an else clause,
is than you cannot typically predict when the enum might be adjusted (by
you or someone else on your team) to have new items which will of course
not be catered to by this and perhaps many other select case statements.

Also, anyone can easily create an enum value that is not defined in the
enum:

Dim x as SearchMgrTables
x = DirectCast(42, SearchMgrTables)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top