471,319 Members | 2,451 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,319 software developers and data experts.

Overriding Dictionary Not Found Exception

Is it possible to override the behaviour of a dictionary if an object is not
found?

string ss=null;
Dictionary<string, string> dict = new Dictionary<string,
string>();

// method 1

try { ss = dict["x"]; }
catch (KeyNotFoundException) {/* Ignore */}

// method 2

if (dict.ContainsKey("x")) ss = dict["x"];

In Method 1, if the key is not there then we have the considerable overhead
of an Exception.
In Method 2 it looks as though we need two dictionary scans.

So is it possible to change the default behaviour of a dictionary so it
returns a null value if not found rather than throwing the exception?

--
Paul
Dec 21 '05 #1
9 6662
Hello!

The Dictionary class is not sealed, so you could create a new concrete
Dictionary with the new functionality. The indexer is not marked virtual, so
you would have to use the "new" keyword when defining the new indexer (you
should make sure that all apropriate methods are re-implemented to ensure
the null-behaviour you're looking for).

Another approach would be to use the Dictionary.TryGetValue() method instead
and adapt your client code to the default non-null behaviour.

--
With regards
Anders Borum / SphereWorks
Microsoft Certified Professional (.NET MCP)
Dec 21 '05 #2
You can use TryGetValue instead.

string ss=null;
Dictionary<string, string> dict = new Dictionary<string,
string>();

if (dict.TryGetValue("x", out ss) == true) {
/* the key was found, and ss now contains the value */
} else {
/* the key wasn't found, and ss is null */
}

Jesse

Dec 21 '05 #3
<=?Utf-8?B?UGF1bHVzdHJpb3Vz?= <msdn_whoisat_paulcotter.com>> wrote:
Is it possible to override the behaviour of a dictionary if an object is not
found?

string ss=null;
Dictionary<string, string> dict = new Dictionary<string,
string>();

// method 1

try { ss = dict["x"]; }
catch (KeyNotFoundException) {/* Ignore */}

// method 2

if (dict.ContainsKey("x")) ss = dict["x"];

In Method 1, if the key is not there then we have the considerable overhead
of an Exception.
In Method 2 it looks as though we need two dictionary scans.

So is it possible to change the default behaviour of a dictionary so it
returns a null value if not found rather than throwing the exception?


You could use Dictionary.TryGetValue - it looks like that's what you're
after.

From a pragmatic (but not elegant) point of view, are you sure that
catching the exception *actually* incurs an overhead which is
significant in your application? You might be surprised just how cheap
exceptions are. See
http://www.pobox.com/~skeet/csharp/exceptions.html for some discussion
on this. I only mention this because many people have bought into the
mantra of "exceptions are expensive" without really looking into it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 21 '05 #4
To All Above... Thanks - next time I will read ALL the methods before
posting. (As an excuse - it IS the last one in the method list :)

To Anders Borum.. TryGetValue is what I need, but I'll give yours a go as a
learning exercise.

--
Paul
Dec 21 '05 #5
HI,

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
I only mention this because many people have bought into the
mantra of "exceptions are expensive" without really looking into it.


I will read you article, but regarding the cost of an exception IIRC even
MS offer that view , that exception are expensive.

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
Dec 21 '05 #6
Jon wrote:
http://www.pobox.com/~skeet/csharp/exceptions.html for some discussion
on this. I only mention this because many people have bought into the
mantra of "exceptions are expensive" without really looking into it.


Very interesting article. My experience has been that the *first* time
an exception is thrown it seems to take a few seconds (presumably
because it has to jit compile the assembly that contains the exception
type), but after that, if the *same* exception is thrown there is
practically no performance hit.

I wonder if there is a way to "pre-load" the exception types during the
start up of the app or is it even worth doing it.

Dec 21 '05 #7
Chris Dunaway <du******@gmail.com> wrote:
http://www.pobox.com/~skeet/csharp/exceptions.html for some discussion
on this. I only mention this because many people have bought into the
mantra of "exceptions are expensive" without really looking into it.


Very interesting article. My experience has been that the *first* time
an exception is thrown it seems to take a few seconds (presumably
because it has to jit compile the assembly that contains the exception
type), but after that, if the *same* exception is thrown there is
practically no performance hit.

I wonder if there is a way to "pre-load" the exception types during the
start up of the app or is it even worth doing it.


Have you experienced that when running a release build not in the
debugger? Do you have a complete program which demonstrates that? I've
only seen that happen in the debugger, which is a very different
situation.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 21 '05 #8
<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT
dot.state.fl.us>> wrote:
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
I only mention this because many people have bought into the
mantra of "exceptions are expensive" without really looking into it.


I will read you article, but regarding the cost of an exception IIRC even
MS offer that view , that exception are expensive.


They're expensive if you're going to end up throwing them thousands and
thousands of times per second - otherwise they're almost always lost in
the noise.

As for whether or not to just follow MS's advice - I tend to trust the
evidence of my own eyes above MSDN. After all, it was only after
badgering them for quite a while that MSDN was changed to admit that
System.Decimal was a floating point type. (It had previously been
inaccurately described as a fixed point type.) MS are just as capable
of making mistakes as the rest of us :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 21 '05 #9
On 21 Dec 2005 06:47:33 -0800, "Chris Dunaway" <du******@gmail.com>
wrote:
Jon wrote:
[snip]
I wonder if there is a way to "pre-load" the exception types during the
start up of the app or is it even worth doing it.


Presumably you could explicitly throw it yourself:

try {
throw new myPreLoadException();
}
catch (myPreLoadException) { /* Do nothing */ }

Whether it is worth doing is another question.

rossum
--

The ultimate truth is that there is no ultimate truth
Dec 28 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by callmebill | last post: by
2 posts views Thread by jg | last post: by
9 posts views Thread by KraftDiner | last post: by
3 posts views Thread by craigkenisston | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.