Whats the difference?

  • Thread starter Thread starter Guest
  • Start date Start date
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
 
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
 
Hi John,
Ok, I get it. Too bad its not smart enough to figure out that the select
case was exhaustive.
 
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
 
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.
 
Terry said:
Hi John,
Ok, I get it. Too bad its not smart enough to figure out that the select
case was exhaustive.
Click to expand...

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...
 
Well, since I operate with option strict on, I trhink all cases are covered
unless there is something else I am missing.
 
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.
 
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
 
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.
 
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.
Click to expand...
 
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.
Click to expand...

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

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