I cannot think of any other errors of consequence that this code could possibly raise, so On Error Resume Next should be fine to use as shown. Perhaps to be safe, though, we might add one more line to protect any other error handlers that might exist “up the line”…

Err.Clear

Make this the last line of code in the function. Without it, the Err object would hold onto any generated error which, if one were not careful, could trip up error trapping code in the calling routine (not very likely, but possible, so we might as well protect against it). We do **not** need to execute an On Error GoTo 0 statement to close the error handler as it will die automatically when the function ends.

So maybe something like

If c(k) doesn’t throw an error, VarType will ALWAYS return an integer, and the integers it returns will NEVER throw overflow/underflow errors when incremented by 1. So only 2 errors could occur: k isn’t a key in c; c is neither a Collection object or Nothing. [Note: Nothing is treated as a Collection with no items/keys.] Trapping all other errors is madness. The only other runtime errors which might occur are environmental ones like no more stack space, out of memory, CPU overheating, etc. Nothing gained trying to trap those.

Good point! I guess we can extend your idea to one of these assignments as well…

f = VarType(c(k)) >= 0

or…

f = IsNumeric(VarType(c(k))

or…

f = VarType(C(k)) Like “#”

This worked when my collections contained strings. But I’ve just spent half an hour tracking down a bug caused by it not working for a collection that contains collections. Presumably because then one needs a

. I note Lon Ingram’s warning about hiding other errors that might raise their heads. But I also like Stephen Bullen’s code, because it’s short and very easy to understand. Lon, or anyone else, what other errors could arise other than the two you make constants for?

Private Const ERR_BAD_ARGUMENT As Long = 5
Private Const ERR_BAD_SUBSCRIPT As Long = 9

Public Function IsInCol(oCol As Object, sKey As String)
Dim f As Boolean

On Error GoTo ErrWrangler

f = IsObject(oCol.Item(sKey))
IsInCol = True

ExitHere:
Exit Function

ErrWrangler:
Select Case Err.Number
Case ERR_BAD_ARGUMENT, ERR_BAD_SUBSCRIPT
IsInCol = False
Err.Clear
Resume ExitHere

Case Else
Err.Raise Err.Number ‘yada yada
End Select
End Function

No variant, too. Woot!

The functions listed all assume that the passed collection is not nothing. They also hide any other error that might rear its head. This would not be a good idea in production code. Why do the On Error Resume Next nonsense when you know what the error will be?

I would do something more along the lines of:

Private Const ERR_BAD_ARGUMENT As Long = 5
Private Const ERR_BAD_SUBSCRIPT As Long = 9

Public Function IsInCol(oCol As Object, sKey As String)
Dim v As Variant

On Error GoTo ErrWrangler

v = oCol.Item(sKey)

IsInCol = True

ExitHere:
Exit Function

ErrWrangler:
Select Case Err.Number
Case ERR_BAD_ARGUMENT, ERR_BAD_SUBSCRIPT
IsInCol = False
Err.Clear
Resume ExitHere

Case Else
Err.Raise Err.Number ‘yada yada
End Select
End Function

I didn’t do much testing on this, so use at your own risk. Should be safer than the other versions posted here. Yes, variants are slow, but so are collections. Code a custom type-specific version if you really need it.

Function IsIn(oCollection As Object, stName As String) As Boolean
Dim O As Object
On Error GoTo NotIn
Set O = oCollection(stName)
IsIn = True
Set O = Nothing

NotIn:
End Function

2. Dictionary Objects do have a builtin method Exists to check whether or not a member exist. This bypasses the ugly ON Error statement. I understand that the use of some Collections (e.g WorkSheets, Charts, …) is imposed by the Excel Object Model but I always wonder why Dictionary Objects (which are much faster and more natural) are not more widely used. Perhaps because you have to include them through a reference to vbscript? (vbscripting runtime?). Any opinions are wellcomed.