I want some Moore

Blog about stuff and things and stuff. Mostly about SQL server and .Net
posts - 218, comments - 2281, trackbacks - 33

My Links

Advertisement

News

Hi! My name is 
Mladen Prajdić  I'm from Slovenia and I'm currently working as a .Net (C#) and SQL Server developer.

I also speak at local user group meetings and conferences like SQLBits and NT Conference
Welcome to my blog.
SQL Server MVP

My Books

SQL Server MVP Deep Dives 2
The Red Gate Guide to SQL Server Team based Development Free e-book

My Blog Feed via Email
Follow MladenPrajdic on Twitter


Users Online: who's online

Article Categories

Archives

Post Categories

Cool software

Other Blogs

Other stuff

SQL stuff

.Net: Passing user data with Exception back to the caller method

We're all familiar (i hope :)) with this construct:

try
{
    // ... some code here ...
}
catch (Exception ex)
{
    // one of these 2 lines are usually seen
    throw; // presereves the full call stack
    //throw ex; // changes the origin of exception to this method
}
finally
{ 
    // more stuff here
}

 

It's a standard error catching routine in .Net.

But what if you want to pass some user info back to the caller method with the Exception being thrown?

Reader... meet Exception.Data. Exception.Data... meet reader.

Now that you're both properly aquainted let see what it does.

Exception.Data is a dictionatry that holds object for key and value. This means that you can put anything into it.

Here's how my standard catch code part looks like:

catch (Exception ex)
{
    // pass the ex to preserve full stac trace
    Exception exNew = new Exception("New exception message", ex);
    exNew.Data.Add("string Data", "data");
    exNew.Data.Add("int data", 1);
    exNew.Data.Add("bool data", true);
    exNew.Data.Add("DateTime data", DateTime.Now);
    // full ex info with user data
    throw exNew;
}

 

I've seen a lot of code and i've never seen this being used. I have seen other way overcomplicated methods being used for the same functionality though. :)

Even though .Data is the first property in the Exception intellisense list it gets overlooked.  How? I have no idea.

 

kick it on DotNetKicks.com

Print | posted on Monday, September 24, 2007 5:36 PM | Filed Under [ .Net ]

Feedback

Gravatar

# re: .Net: Passing user data with Exception back to the caller method

Careful if you want to use this in a Webservice!

I was told, that you can run into problems if using this in a Webservice scenario, because the serializeability is affected and the exception can't be transfered correctly.

For more information look at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1649014&SiteID=1 for example.

Besides that it is a great hint!
10/8/2007 10:57 AM | Deniz
Gravatar

# re: .Net: Passing user data with Exception back to the caller method

thanx for letting us know about this deniz. thanx!
10/8/2007 10:58 AM | Mladen
Gravatar

# re: .Net: Passing user data with Exception back to the caller method

This short article is more useful than everything I've readed about exceptions so far.
6/4/2009 11:04 PM | Manuel
Gravatar

# re: .Net: Passing user data with Exception back to the caller method

This is EXTREMELY useful and I agree with Manuel more useful than most things I've read about exceptions to date.
2/6/2010 6:20 PM | Machina
Gravatar

# re: .Net: Passing user data with Exception back to the caller method

I found a problem with a technique I'm using in my logging to prevent the same exception from being logged multiple times: adding flags to the Exception Data collection.

It appears on the surface that somehow certain .NET framework features try to re-use instances of an exception, causing flags added to the 'Data' collection to appear to have been set when they are really just hanging around from a previous time when the exception was thrown and the flag added...

Specifically, I found this to be true with the SqlException class.

Try this:

public static void foo(string connectionString) {
try{
SqlConnection cn = new SqlConnection (connectionString);
cn.Open();
}
catch (SqlException ex) {
if (ex.Data.Contains("MY_TEST_FLAG"))
Debug.WriteLine("BAD! It Shouldn't be there yet!");
else
Debug.WriteLine("Fine.");

ex.Data.Add("MY_TEST_FLAG", true);
}
}

Call foo() several times with a connection string that is vaild in format, but with perhaps a bad UID value. The first time you call FOO, I get the "Fine." message when the bad connection string causes the Connection object to throw a SqlException, but each time after that, I get the "BAD!" message (for a while, eventually I'll get a "Fine" message again, once, then more "BAD!" messages).

If each time I try to create a SqlConnection with a bad connection string were really resulting in completely unique instances of SqlException to be thrown, I'd get the "Fine" message every time!

I'd love it if someone could explain that to me!

3/1/2010 11:01 PM | TWheelhouse
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET