Remove from Hashtable? [easy one]

[Jules Winfield]

I'm often in a situation where I have a Hashtable full of objects. I'm
then presented with an object and *if* that object exists in the Hashtable,
I need to remove it from the table. I therefore have a lot of code that
looks like this:

if(ht.Contains(obj)){
ht.Remove(obj);
}

It strikes me that this code is somewhat inefficient because the
Hasthtable has to be searched *twice* : once for the Contains() call and
once for the Remove() call. So I thought maybe I should approach the
situation this way:

try{
ht.Remove(obj);
}
catch(Exception){}

Now I'm only searching the Hashtable once... but is the overhead of
throwing the exception cancelling out any benefit that I achieved by not
calling Contains()? To answer this question, you probably need to know how
frequently 'obj' is actually found in the Hashtable. For the sake of
argument, let's say 50%.

Thanks,

Jules

[Jules Winfield]

Thanks for the tips, guys. I won't concern myself with trivial
optimizations like this unless I see that there's a performance bottleneck.

Jules

[Micahel Oberberger]

Jules-

i am confused at what you're doing here.

According to everything in my experience (including reading reading the
docs), Hashtable.Remove only throws an exception if the argument is null, the
table is read-only, or the table has a fixed size.

A Simple Element-Not-Found does NOT throw an exception.

Just Remove away!

now... if you were trying to properly catch all exceptions, then you should
have also looked for ArgumentNullException as well as NotSupportedException,
but that's immaterial to the examples you've presented.

No performance penalty at all =)
"Jules Winfield" wrote:

I'm often in a situation where I have a Hashtable full of objects. I'm
then presented with an object and *if* that object exists in the Hashtable,
I need to remove it from the table. I therefore have a lot of code that
looks like this:

if(ht.Contains(obj)){
ht.Remove(obj);
}

It strikes me that this code is somewhat inefficient because the
Hasthtable has to be searched *twice* : once for the Contains() call and
once for the Remove() call. So I thought maybe I should approach the
situation this way:

try{
ht.Remove(obj);
}
catch(Exception){}

Now I'm only searching the Hashtable once... but is the overhead of
throwing the exception cancelling out any benefit that I achieved by not
calling Contains()? To answer this question, you probably need to know how
frequently 'obj' is actually found in the Hashtable. For the sake of
argument, let's say 50%.

Thanks,

Jules

[Jules Winfield]

> A Simple Element-Not-Found does NOT throw an exception.

Ha! You're right!

I've been calling Contains() before removing since the tech preview of the
original .NET back in like 2000 or 2001 or so. I've been doing it because I
read in a tutorial that you were supposed to do this. Either the tutorial
was completely wrong or the beta version of .NET that I was using back then
actually did throw an exception when Remove() was called with an keythat
doesn't exist in the Hashtable. It's funny how a bad habit learned back in
2001 stuck with me all of these years.

Despite the moot point re:Remove(), a similar issue caught my attention
recently with the IDictionary<T> Item (that is, [] indexer) property. It
throws an exception when the key isn't found, unlike it's non-generic
counterpart which simply returns null. It looks like Microsoft addressed the
issue with a new method called TryGetValue(), which acts a lot like the []
indexer but won't throw an exception when the key isn't found.

Jules