Try..Catch...Now What

What's interesting is that if you look into the source code that Microsoft provides in the Enterprise Libraries, starter kits, and code samples, both in C# and VB.NET, you'll see code like you're talking about there too.

The thing about Close is interesting. Do you know if this should happen for all classes with the IDisposable interface? It seems like it should but I've seen some odd behavior with some objects when Close wasn't called even though a Using block was there.

Hmmm... "should" is tricky verbage. This brings up a good point though. I know that it's superfluous to add the try...finally around the connection usage, but really, this is in hind site. Meaning, had I not seen whatever it was that informed me of the whole "...calling dispose results in calling close...." blah blah blah .... I guess my point is this, the assumption is that calling dispose, will handle cleaning up of any resources that may be out of your control. Should it be a requirement that anyone with a 'Close' method be required to call that method within dispose? As of the time of this writing, I say no, but I reserve the right to change my mind pending any other information :)

"Where's the value add? What's the point of catching an exception if you're not going to do anything with it? Here's another good one"

The only thing I can think, and I see this a lot (a long with other useless crap in the catch block like string x = e.Message) is that it provides a place for a breakpoint...

@Joe, that's another good one "string x = e.Message", I just saw this one this morning, good grief:
public static int SomeMethod(){
try{
*snip*
}
catch (Exception e){
result = -999;
throw e;
}
}


look up this:

try
{
[ something iffy ]
}
catch
{
throw; <-- note minimal syntax.
}

try
{
[ something iffy ]
}
catch
{
throw; <-- note minimal syntax.
}

I had a "team member" give me static for not explicitly calling "connection.Close()" when I had my connection in a using-construct.

Needless to say, I don't work for that company anymore.


using (SqlConnection connection = GetConnection())
using (SqlCommand command = new SqlCommand("command", connection))
{
connection.Open();
cm.CommandType = commandType;

using (IDataReader reader = command.ExecuteReader(..))
while (reader.Read())
}


I feel that when I do use a try-catch it is for a specific exception (i.e. SqlException).

I just lol'ed @ "shit code"

"I feel that when I do use a try-catch it is for a specific exception (i.e. SqlException)."

Yep, and if you catch a SqlException you'll probably be logging the sql that caused that exception, and/or rolling back the transaction if you're in one, or any number of things that would be a value add to catching the exception in the first place.

"@tom, even though the code is catching the exception and re-throwing the original exception, there's still no value add, why catch it in the first place?"

I'm not Tom but it makes debugging a hell of a lot easier. You can place a breakpoint there and see your vars, etc.

What the-

Who the-

breakpoint??

why would you need a breakpoint on a new exception?

Why not just break on the violator who threw the original exception?

.NET Using strings and enum - C# .NET Using .NET Custom Attributes for release documentation Book: Announcing

I'm not sure if things have changed since ASP.NET 1.1, but there is an issue with nested 'using' statements. What would happen is, if a nested disposable object throws an exception then the outter objects wouldn't get disposed.

Also, doesn't each 'using' statement create it's own try/catch statement meaning there are 2 for every connection? If my assumptions are correct then it's more efficient to write your own try/catch statement, albiet less readable.

Hmmm, not sure about a problem with nested usings, hadn't heard of one but that'd be good info.

As for each using generating it's own try/finally, that's to ensure that whatever object supports IDisposable is guaranteed to have it's own Dispose called, so a single try/catch around a connection and a command would need to ensure that Dispose is called on both the Command and the Connection.

More efficient? I have no clue either way. More readable? yep, I'll stick with more readable until .NET 5.0 comes out and the nested using's become the new "shit code" :)

Oops, I made a mistake. I misread the passage from "Effective C#" by Bill Wager that covers this topic. The bug I describe only happens if you do:


using (myConnection as IDisposable)
using (myCommand as IDisposable)
{ ... }


My appologies. However, the book confirmed that:


using (SqlConnection myConnection = new SqlConnection( ... ))
using (SqlCommand myCommand = new SqlCommand( ... ))
{ ... }


results in IL equivilent to:


try
{
SqlConnection myConnection = new SqlConnection( ... );
try
{
SqlCommand myCommand = new SqlCommand( ... );
...
}
finally
{
if(myCommand != null)
myCommand.Dispose();
}
}
finally
{
if(myConnection != null)
myConnection.Dispose();
}


Thats pretty ugly but you're right, now I think about it I doubt it would incure much of a performance hit.

Anyways, thanks for the reply and the great blog!